[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [PATCH] CPUIDLE: shorten hpet spin_lock holding time
On 20/04/2010 17:05, "Wei, Gang" <gang.wei@xxxxxxxxx> wrote: > Resend. > > CPUIDLE: shorten hpet spin_lock holding time > > Try to reduce spin_lock overhead for deep C state entry/exit. This will > benefit systems with a lot of cpus which need the hpet broadcast to wakeup > from deep C state. > > Signed-off-by: Wei Gang <gang.wei@xxxxxxxxx> It fixes the unsafe accesses to timer_deadline_{start,end} but I still think this optimisation is misguided and also unsafe. There is nothing to stop new CPUs being added to ch->cpumask after you start scanning ch->cpumask. For example, some new CPU which has a timer_deadline_end greater than ch->next_event, so it does not reprogram the HPET. But handle_hpet_broadcast is already mid-scan and misses this new CPU, so it does not reprogram the HPET either. Hence no timer fires for the new CPU and it misses its deadline. Really I think a better approach than something like this patch would be to better advertise the timer_slop=xxx Xen boot parameter for power-saving scenarios. I wonder what your numbers look like if you re-run your benchmark with (say) timer_slop=10000000 (i.e., 10ms slop) on the Xen command line? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |