Forgot below comment and I read your patch too quickly.
It's supposed to work, and maybe some sequence issue reverts
the effect you want to achieve. For example, at least the lines
within init_xen_time is useless, since calibrate_tsc_ap happens
later which will update AP tsc_scale. Anyway, this looks in a
right direction, and we'll do some debug to find the exact reason.
Thanks,
Kevin
>From: Tian, Kevin
>Sent: Tuesday, December 16, 2008 8:29 AM
>
>>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
|