[Xen-devel] Re: [PATCH?] monotonically increasing Xen system time

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

Xen itself doesn't in most cases care about a bit of skew across CPUs. So I
think the cuurent get_s_time() is fine, and then build monotonicity on top
where we want it (notably hvm_get_guest_time() as has already been done).

 -- Keir

On 28/7/08 18:04, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

> (This is probably post-3.3, but feedback would be appreciated
> as I would hope it could go into 3.3.1 if it doesn't make 3.3.)
> 
> I've finally surrendered to the fact that intra-CPU stime skew
> can't be reduced down to the point where it can be ignored,
> at least on non-tsc-invariant boxes.  It always seems to
> max out at least at several microseconds, and in some cases
> in tens of microseconds.  This is probably a result of
> crystal oscillation drift, and perhaps the "beating" of
> the platform timer crystal vs the tsc crystal.
> 
> So the attached patch adds a get_s_time_mono() call that
> always returns a monotonically INcreasing (not just
> non-decreasing) stime.  A stime_minstep is computed that
> guarantees that mono_stime can't increase faster than
> stime, even if all processors are pounding on stime
> in a loop.  The result is the resolution for mono_stime.
> (On my dual-core box, it's 24ns... your mileage may vary.)
> 
> I want to use this in hvm_get_guest_time() (and thus for
> softtsc) but it may also be appropriate for at least some
> of the many uses of NOW() in Xen.  If so, it might make
> sense that this should be the default get_s_time() and the
> current get_s_time() should be renamed get_local_s_time().
> In any case, there are most likely other uses for it
> in Xen so I didn't want to build it just into
> hvm_get_guest_time().
> 
> (Note that init_xen_time() was moved down in __start_xen()
> because num_online_cpus() gave the wrong answer at its
> current position.)
> 
> Signed-off-by: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
> 
> ===================================
> Thanks... for the memory
> I really could use more / My throughput's on the floor
> The balloon is flat / My swap disk's fat / I've OOM's in store
> Overcommitted so much
> (with apologies to the late great Bob Hope)



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel