RE: [Xen-devel] [PATCH] time-xen : Reset monotonic time when sync up time from dom0 to domU

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx]
> Sent: Thursday, October 14, 2010 3:08 AM
> To: Jeremy Fitzhardinge
> Cc: Dan Magenheimer; Jan Beulich; Hang Du; Keir Fraser; Saipu Liu;
> Shunli Yi; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH] time-xen : Reset monotonic time when
> sync up time from dom0 to domU
> 
> At 17:48 +0100 on 13 Oct (1286992083), Jeremy Fitzhardinge wrote:
> > > There was a paper about this at OSDI last week:
> > > http://www.usenix.org/events/osdi10/tech/full_papers/Broomhead.pdf
> >
> > Ooh, look, RADclock, just what I was thinking about.
> 
> Yes, it looks pretty good.  Also they can use Xen stime as the local
> oscillator and distribute drift numbers from xenstore, so no hypervisor
> patches (and no hypervisor-interface changes) required. :)

Maybe I'm misunderstanding the paper, but isn't it required
that Xen stime be directly readable for every attempt to
sample time (e.g. requiring at least some small interface
change such as adding a hypercall to obtain Xen stime)?
The current pvclock mechanism still depends on TSC to
interpolate between "Xen stime samples periodically written
to memory" to get adequate precision.

Also, for those certain enterprise applications that want
to sample time 10000+ samples/second/processor, and need
to know "immediately" when a sample might be bad (due
to, for example, live migration), I think each sample would
need to check xenstore.  Is xenstore up to that kind of
pounding (and is it fast enough)?

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