At 15:09 +0100 on 15 Oct (1287155382), Dan Magenheimer wrote:
> > 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)?
You can obtain xen stime directly from the shared-into page and RDTSC.
There might need to be _kernel_ changes to make that available to
userspace, though my impression is that they push packet-timestamping
into the kernel.
> 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)?
No it's certainly not (either of those things), but:
- the problem of turning a distributed wallclock into something suitable
for timestamping that aggressively is orthogonal to the problem of
distributing that wallclock in the first place; and
- all the user really needs is a generation counter to know that the
clock correction values are stale, and the kernel can provide that
alongside the stime.
Cheers,
Tim.
--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home