|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [Xen-devel] [PATCH] time-xen : Reset monotonic time when sync up tim
To: |
Tim Deegan <Tim.Deegan@xxxxxxxxxx> |
Subject: |
RE: [Xen-devel] [PATCH] time-xen : Reset monotonic time when sync up time from dom0 to domU |
From: |
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> |
Date: |
Fri, 15 Oct 2010 07:46:46 -0700 (PDT) |
Cc: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxx>, Shunli Yi <syi@xxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Saipu Liu <saliu@xxxxxxxxxxxx>, Hang Du <hdu@xxxxxxxxxxxx> |
Delivery-date: |
Fri, 15 Oct 2010 07:48:47 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<20101015141959.GN4007@xxxxxxxxxxxxxxxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<9C56B6AEEB2D60488B29B880DF7E53BE03C1B2C6B6@xxxxxxxxxxxxxxxxxxxxx> <4CB4672E020000780001C752@xxxxxxxxxxxxxxxxxx> <0b6cc1b3-f838-482e-89dc-6f19cc8c47cc@default> <20101013161657.GJ4007@xxxxxxxxxxxxxxxxxxxxxxx> <189f03c1-4b74-4f13-9e0c-f614d51522a0@default 20101015141959.GN4007@xxxxxxxxxxxxxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
> > 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
Agreed that this is a better solution to a very important problem.
I'm just trying to determine if it helps solve another time-related
real world problem.
> - 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.
Agreed that a generation counter solves this. BUT...
(1) afaik there is no generation counter in any time-related
kernel API; and
(2) afaict this generation counter would need to be "pushed"
from the dom0 kernel so would either (a) require domU kernels
to read from xenstore, or (b) require some kind of privileged
hypercall from dom0 to the hypervisor telling the hypervisor
to change the generation counter (and scaling values?) for all
domUs.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|