[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Re: [PATCH] CPUIDLE: revise tsc-save/restore to avoid big tsc skew between cpus
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |