Skip to content
Snippets Groups Projects
  1. Jan 27, 2014
    • Nadav Har'El's avatar
      clock: Use monotonic clock in the thread scheduler · d73fe79c
      Nadav Har'El authored
      
      Switch the thread scheduler from using the s64 type for durations and
      the wall time, to the osv::clock::uptime::duration type (which is
      std::chrono::nanoseconds) and monotonic clock.
      
      Also, now that the per-thread CPU-time clock (thread::thread_clock())
      returns an std::chrono::duration instead of s64, we no longer need the
      fill_ts(s64) variant in libc/time.cc (if we leave it unused, we'll get a
      compilation warning).
      
      Reviewed-by: default avatarGlauber Costa <glommer@cloudius-systems.com>
      Signed-off-by: default avatarNadav Har'El <nyh@cloudius-systems.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      d73fe79c
    • Nadav Har'El's avatar
      clock: Allow comparison of std::chrono::duration with 0 · af540799
      Nadav Har'El authored
      
      Durations cannot be compared with unit-less integers: one cannot just
      check d < 7: One needs to do something like d < 7_ms.
      
      Unfortunately, this rule also applies to zero: d < 0 won't work, and users
      need to add a unit to the zero. Of course, any unit would work: d < 0_ms,
      or d < 0_ns, or any other time unit. For physicists, this requirement
      makes perfect sense (even zero has units), but for most programmers, the
      extra units would seem surprising and redundant.
      
      This patch makes it possible to compare a std::chrono::duration to
      0 without needing to add a unit, while still leaving comparison with a
      non-zero integer an error.
      
      This is convenient for us because existing code which compared s64
      durations to unit-less 0, will continue to work unmodified after we
      switch from s64 to std::chrono::duration.
      
      Reviewed-by: default avatarGlauber Costa <glommer@cloudius-systems.com>
      Signed-off-by: default avatarNadav Har'El <nyh@cloudius-systems.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      af540799
    • Nadav Har'El's avatar
      clock: base timers on monotonic clock · 477b9427
      Nadav Har'El authored
      
      sched::timer_base, used to implement all forms of timeouts in OSv, is
      currently based on the wall-clock time in s64 form. This is problematic
      for two reasons:
      
      1. The type s64 doesn't say which units should be used, whether the time
      is absolute or relative or what is its epoch.
      
      2. wall-clock time is a bad choice for short-term timers: If a thread
      intends to sleep for a millisecond, and the wall-clock goes back a minute,
      the thread will end up sleeping a whole minute.
      
      So this patch changes the basis of sched::timer_base to strongly-typed
      time points from a monotonic clock, osv::clock::uptime::time_point.
      
      We also allow setting timers using the wall-clock time, but with a big
      caveat: The expiration time is converted from wall to uptime clocks at
      the moment of timer_base::set(), so if the wall-clock is adjusted later,
      the wall time at expiration may not be exactly the one intended.
      
      So that we don't have to change all timer users in this one patch, we
      also temporarily implement the old weakly-typed timer_base::set(s64)
      using the new mechanism. This variant will be removed in a later patch
      in this series, when it is no longer used.
      
      Reviewed-by: default avatarGlauber Costa <glommer@cloudius-systems.com>
      Signed-off-by: default avatarNadav Har'El <nyh@cloudius-systems.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      477b9427
    • Nadav Har'El's avatar
      clock: temporary alias osv::clock::get() for clock::get() · 0b462341
      Nadav Har'El authored
      
      Unfortunately, sched.cc uses "using namespace osv" causing a big mixup
      between ::clock (from <drivers/clock.hh>) and osv::clock (from
      <osv/clock.hh>). In the next patch, we want to start using <osv/clock.hh>
      in sched.cc, so we need to first clear this mixup by temporarily adding
      an alias osv::clock::get(), to resolve the clock::get() used throughout
      sched.cc.
      
      In later patches in this series, we'll remove all the calls to clock::get(),
      from sched.cc, so at the end of the series we revert this patch.
      
      Reviewed-by: default avatarGlauber Costa <glommer@cloudius-systems.com>
      Signed-off-by: default avatarNadav Har'El <nyh@cloudius-systems.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      0b462341
    • Nadav Har'El's avatar
      clock: Add clock::boot_time() function · 3cc0e96f
      Nadav Har'El authored
      
      Currently, OSv's sched::timer mechanism supports only the wall clock
      clock::get()->time(). In the following patches, we intend to support both
      wall-clock and monotonic clock in timers, but only keep a single list of
      timers (using the monotonic clock).
      
      For this, we need a way to convert wall-clock time to monotonic uptime.
      This patch adds to the clock driver a function clock::boot_time() which
      returns the current offset between the wall time and the uptime, i.e., the
      current estimate of the wall time at boot. Note that this estimate can
      change if the wall time is adjusted (in the host, since OSv currently has
      no mechanism for adjusting the clock from within).
      
      Reviewed-by: default avatarGlauber Costa <glommer@cloudius-systems.com>
      Signed-off-by: default avatarNadav Har'El <nyh@cloudius-systems.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      3cc0e96f
    • Nadav Har'El's avatar
      clock: add clock_event::set(timepoint) · 9781a6f2
      Nadav Har'El authored
      
      In the previous patch we built clock_event::set(s64) on top of
      set(duration). In this patch we add set(timepoint), for absolute time
      in any clock supporting the now() static method. In the following patches,
      we'll convert our timers to using the monotonic clock osv::clock::uptime,
      and use timepoints of that clock in calls to clock_event::set().
      
      By temporarily having both s64 and std::chrono:time_point versions
      of set(), we make this patch series bisectable. At the end of this series,
      the s64 variant will be removed.
      
      Reviewed-by: default avatarGlauber Costa <glommer@cloudius-systems.com>
      Signed-off-by: default avatarNadav Har'El <nyh@cloudius-systems.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      9781a6f2
    • Nadav Har'El's avatar
      clock: relative-time clock_event::set() · 5c5f5971
      Nadav Har'El authored
      
      OSv's timer mechanism hinges on the Local APIC's (per-cpu) one-shot timer,
      which delivers an interrupt after the requested number of nanoseconds.
      
      The API to set this timer, clock_event::set(), took the absolute time of
      the next interrupt. However, what it really needs is the duration in
      nanoseconds until the next interrupt.
      
      So this patch we change the basic clock_event::set() API to take a
      duration, and implement the original clock_event::set(s64) - taking an s64
      absolute wall-clock time - as a simple wrapper.  The next patch will add
      more wrappers for set() taking absolute times from different clocks.
      Later patches in this series will stop using the old set(s64) version,
      until it is dropped in the end of the series.
      
      Reviewed-by: default avatarGlauber Costa <glommer@cloudius-systems.com>
      Signed-off-by: default avatarNadav Har'El <nyh@cloudius-systems.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      5c5f5971
    • Nadav Har'El's avatar
      clock: Avoid #include <drivers/clockevent.hh> · e1c4aa82
      Nadav Har'El authored
      
      Several source files include <drivers/clockevent.hh>, though this is a
      very low-level feature which they don't actually use.
      
      sched.cc does use <drivers/clockevent.hh>, but already gets it through
      sched.hh, so also doesn't need to include it explicitly.
      
      This patch removes the unnecessary includes.
      
      Reviewed-by: default avatarGlauber Costa <glommer@cloudius-systems.com>
      Signed-off-by: default avatarNadav Har'El <nyh@cloudius-systems.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      e1c4aa82
  2. Jan 26, 2014
  3. Jan 24, 2014
    • Glauber Costa's avatar
      balloon: fix the double move problem · 4eb7d9c2
      Glauber Costa authored
      
      As we have recently discovered, some parallel GCs will move an object to two
      different locations at times, and later on decide on which one to use. This
      breaks our implementation if the final object is the second one to be copied,
      because by then the original region is already mapped - so we won't fault, and
      the unmapped region will not be the actual balloon, so we will have a bogus
      fault
      
      The core of this solution is to keep all the regions unmapped. Because they had
      only garbage before, we know Java shouldn't read anything from it before it
      writes something new. And when it does that, we declare that to be no longer a
      balloon.
      
      Movement is then split in two phases: the normal phase, and the finish phase.
      In the finish phase we will remove the old VMA and create the new VMA again,
      with heap characteristics.
      
      Special care needs to be taken when "conciliating" the array: because we use
      the difference between first faulting address and original array address to
      calculate how many bytes we are skipping, we need to store that information
      somewhere. We're using an unordered_map (hash) for that. We'll keep track of
      all in-flight ballooned regions and hold the original address of the array.
      
      When we detect movement *from* that region, we know it is the new location
      and update the balloon object with the new address.
      
      Signed-off-by: default avatarGlauber Costa <glommer@cloudius-systems.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      4eb7d9c2
    • Glauber Costa's avatar
      balloon: store flags from original vma when ballooning · 95c644dc
      Glauber Costa authored
      
      To avoid using hard code values for the original anonymous vma that mapped the
      region before we ballooned, let's store the original flags in the JVM vma. This
      patch does not yet use it, but only lays down the infrastructure. User will
      come in the next patch.
      
      Signed-off-by: default avatarGlauber Costa <glommer@cloudius-systems.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      95c644dc
    • Glauber Costa's avatar
      balloon: introduce a conciliation phase · 2b8ceebc
      Glauber Costa authored
      
      This patch introduces a separate operation, "conciliate", that calculates
      the balloon parameters given an arbitrary address
      
      Signed-off-by: default avatarGlauber Costa <glommer@cloudius-systems.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      2b8ceebc
    • Glauber Costa's avatar
      mmu: give the jvm balloon write permissions · 54b1d4dc
      Glauber Costa authored
      
      Up until now the JVM balloon explicitly forbade writes to its range, because
      we didn't expect the JVM to ever write to it. But with the recently problem
      Gleb discovered of double-copying of objects inside the Heap, we will use
      writes to figure out when that object is no longer a balloon. But still,
      we need to be able to go back to the JVM specific fault handler for that.
      
      Therefore, we need write permissions in the VMA itself.
      
      Signed-off-by: default avatarGlauber Costa <glommer@cloudius-systems.com>
      [ penberg: use perm_rw as suggested by gleb ]
      Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      54b1d4dc
    • Glauber Costa's avatar
      balloon: fix stack-like behavior for balloons · 5d83b36d
      Glauber Costa authored
      
      We should always remove the last balloon we've created. There are two main
      reasons for that:
      
      1) The older balloons are likely to be already in more tenured generations,
      and will move less, whereas younger balloons could be in younger generations.
      So by removing them like a stack, we'll avoid needless moves
      
      2) The probe, when inserted, should stay for as long as we can.
      
      That was always the intended behavior but I made the small mistake of inserting
      them in the wrong order. Fix that.
      
      Signed-off-by: default avatarGlauber Costa <glommer@cloudius-systems.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      5d83b36d
  4. Jan 23, 2014
  5. Jan 22, 2014
Loading