RE: [Xen-devel] Ticket spinlocks and MP guests

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
>Sent: 2008年2月15日 16:53
>
>On 15/2/08 08:42, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>>> You would of course spin for a while and only then sleep.
>>> That's a standard
>>> mutex implementation trick.
>>> 
>> 
>> I'm not sure how to define 'a while', since even for same critical
>> section the spin cycles varies at different point. You always risk
>> adding more overhead than a normal spin loop. But well, it depends
>> on how frequent forementioned case may occur, and the gain
>> of pv'ed spinlock may be larger than overhead it causes.
>
>You could certainly end up in the situation that the lock 
>becomes available
>just after you decide to sleep, no matter what spin threshold 
>you choose.
>It's a balance of probabilities: e.g., if you spin for 1us, what is the
>probability distribution of remaining wait time? If the lock-holder is
>preempted then you are likely to spin for ages. That, coupled with most
>spinlock regions in the kernel being very fast, means that we 
>wouldn't need
>to be very smart to filter out the former cases without 
>hurting performance
>in the latter. The distribution of waits will be very 
>obviously bimodal.
>
> -- Keir

Yes, that makes sense. It can be extended to cover ticket spinlock
usage, like forcing sleep if smaller ticket is already in, and only 
wake vcpu with 'next' ticket at unlock, etc. :-)

Thanks,
Kevin

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