[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
>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 |