[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [PATCH] time-xen : Reset monotonic time when sync up time from dom0 to domU
> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |