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