Again, another wrong comment was given by me since the
sequence is correct. Not sure my bad mind in such a good
morning. :-( Jimmy is now trying your suggestion to sync
TSC MSR in time calibration softirq.
Thanks,
Kevin
>From: Tian, Kevin
>Sent: Tuesday, December 16, 2008 8:45 AM
>To: Tian, Kevin; 'Keir Fraser'; Wei, Gang;
>
>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
|
Home