RE: [Xen-devel] Re: [PATCH] CPUIDLE: revise tsc-save/restore to avoid big tsc skew between cpus

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] 
>Sent: Tuesday, December 16, 2008 12:02 AM
>
>On 15/12/2008 13:28, "Wei, Gang" <gang.wei@xxxxxxxxx> wrote:
>
>>>> Redo the constant_tsc & tsc_nostop check part and post it again.
>>> 
>>> I applied the bits outside time.c. For time.c itself, how 
>about the simpler
>>> attached alternative? Does it work well? :-)
>> 
>> Although it looks simpler & workable, but the practice shows 
>it doesn't work.
>
>Weird. I wonder if CPU TSCs aren't as synced as we'd like, and 
>we're getting
>a -ve TSC delta in get_s_time(). Perhaps setting the TSC MSR to
>r->master_tsc_stamp in time_calibration_rendezvous() would avoid that.
>

I'm not sure why you don't want to adjust TSC. Whether cpu TSCs
are sync-ed or not doesn't make sence if TSC will stop when
individual core enters deep C-state. As long as multiple cpus get
difference chance in deep C-state, finally you always has increasing
TSC skews. Whatever you can do in Xen side w/o adjusting TSC,
it only helps those aware of xen system time, e.g. pv guest. However
for hvm guest, TSC skew always causes problem.

I think no software approach can cleanly solve this TSC skew, unless
with hardware assistance like always running tsc. Since Jimmy's
approach can work far better than previous one, (yes, we know some
weakness when one cpu doesn't enter deep C-state for a long time),
it's still worthy of slipping in? In the meantime, IMO your change can
be also required, since there's no much need for periodic time calib-
ration upon a constant tsc feature. But it's a seperate issue as we
aim to solve. :-)

Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel