[Xen-devel] RE: [PATCH] CPUIDLE: shorten hpet spin_lock holding time

["Wei, Gang" <gang.wei@xxxxxxxxx>]

On Tuesday, 2010-4-20 8:49 PM, Keir Fraser wrote:
> Is this a measurable win? The newer locking looks like it could be
> dodgy on 32-bit Xen: the 64-bit reads of timer_deadline_{start,end}
> will be non-atomic and unsynchronised so you can read garbage. Even
> on 64-bit Xen you can read stale values. I'll be surprised if you got
> a performance win from chopping up critical regions in individual
> functions like that anyway. 

First of all, this is a measurable power win for cpu overcommitment idle case 
(vcpu:pcpu > 2:1, pcpu >= 32, guests are non-tickless kernels).

As to the non-atomic access to timer_deadline_{start,end}, it should already be 
there before this patch. It is not protected by the hpet lock. Shall we add 
rw_lock for each timer_deadline_{start,end}? This can be done separately.

Jimmy
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel