This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] [PATCH] time-xen : Reset monotonic time when sync up tim

> 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

<Prev in Thread] Current Thread [Next in Thread>