|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation
To: |
john stultz <johnstul@xxxxxxxxxx> |
Subject: |
RE: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation |
From: |
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> |
Date: |
Wed, 4 Nov 2009 16:45:04 -0800 (PST) |
Cc: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, kurt.hackel@xxxxxxxxxx, Glauber Costa <glommer@xxxxxxxxxx>, maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Glauber de Oliveira Costa <gcosta@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Avi Kivity <avi@xxxxxxxxxx>, the, Ingo Molnar <mingo@xxxxxxxxxx>, zach.brown@xxxxxxxxxx, chris.mason@xxxxxxxxxx, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> |
Delivery-date: |
Wed, 04 Nov 2009 16:47:28 -0800 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<1257379338.10811.152.camel@xxxxxxxxxxxxxxxxxxxxx> |
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> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
> > Yes, possibly of interest. But does it work with CONFIG_NO_HZ?
> > (I'm expecting that over time NO_HZ will become widespread
> > for VM OS's, though interested in if you agree.)
>
> It should work, with CONFIG_NO_HZ, as soon as we come out of
> a long idle
> (likely due to a timer tick), the timekeeping code will accumulate all
> the skipped ticks.
>
> If we ever get to non-idle NOHZ, we'll need some extra work here
> (probably lazy accumulation done conditionally in the read path), but
> that's also true for filesystem timestamps.
OK, sounds good.
> > Also very interested in your thoughts about a variation
> > that returns something similar to a TSC_AUX to notify
> > caller that the underlying reference clock has/may have
> > changed.
>
> I haven't been following that closely. Personally, experience makes me
> skeptical of workarounds for unsynced TSCs. But I'm sure
> there's sharper
> folks out there that might make it work. The kernel just requires that
> it *really really* works, and not "mostly" works. :)
This is less a workaround for unsynced TSCs than it
is for VM migration (and maybe also time where a
VM is out-of-context or moved to a different pcpu)
though it could probably
be made to work on unsynced TSC boxes also.
Basically an application needing hi-res profiling
info would do:
nsec1 = clock_gettime2(MONOTONIC,&aux1);
(time passes)
nsec2 = clock_gettime2(MONOTONIC,&aux2);
if (aux1 != aux2)
discard_measurement();
else
use_measurement(nsec2-nsec1);
and system software (hypervisor or kernel or
both) is responsible for ensuring aux value
monotonically increases whenever a different
crystal is used.
Without something like this as a vsyscall,
apps will just use rdtscp (which must be emulated
to work properly across a migration).
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|