|  |  | 
  
    |  |  | 
 
  |   |  | 
  
    |  |  | 
  
    |  |  | 
  
    |   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
 | 
 |  | 
  
    |  |  |