This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

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


Xen-devel mailing list