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

[Espen Skoglund <espen.skoglund@xxxxxxxxxxxxx>]

[Keir Fraser]
> 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.

Just as a sidenote: When we measured the 2.4 kernel years ago we found
that more than 90% of the spinlocks were held for less than 20us (on
very kernel intensive workloads).  That number is likely to be much
smaller today.

        eSk




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