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

["Wei, Gang" <gang.wei@xxxxxxxxx>]

On Tuesday, December 16, 2008 12:02 AM, Keir Fraser wrote:
> 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 added a conditional wrmsrl as you said, meanwhile removed unnecessary 
c->master_tsc_stamp. It works fine now.

Below 't' key outputs are gotten in the extreme case: pin all dom0 & guest 
vcpus on cpu1 & execute cmd 'while true; do a=1; done' within one guest.
The largest stime skew is ~40us, largest cycles skew is ~100,000 ticks(~40us). 
The normal idle case skew is quite small (~xxxns).

(XEN) Synced stime skew: max=39662ns avg=8038ns samples=850 current=326ns
(XEN) Synced cycles skew: max=100475 avg=20368 samples=850 current=825
...
(XEN) Synced stime skew: max=39750ns avg=16958ns samples=3954 current=30667ns
(XEN) Synced cycles skew: max=100708 avg=42967 samples=3954 current=77696
...
(XEN) Synced stime skew: max=39750ns avg=17318ns samples=4544 current=22981ns
(XEN) Synced cycles skew: max=100708 avg=43880 samples=4544 current=58225

Jimmy

Attachment: tsc-2.patch
Description: tsc-2.patch

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