Re: [Xen-devel] [PATCHv2 5/6] xen: use ticket locks for spin locks

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.04.15 at 14:03, <tim@xxxxxxx> wrote:
> At 15:19 +0100 on 10 Apr (1428679196), David Vrabel wrote:
>> Replace the byte locks with ticket locks.  Ticket locks are: a) fair;
>> and b) peform better when contented since they spin without an atomic
>> operation.
>> 
>> The lock is split into two ticket values: head and tail.  A locker
>> acquires a ticket by (atomically) increasing tail and using the
>> previous tail value.  A CPU holds the lock if its ticket == head.  The
>> lock is released by increasing head.
>> 
>> Architectures need only provide an xadd() implementation.
> 
> I like this.  Thanks for measuring the IRQ latency too -- that's the
> most nervous-making part of the overall change. 

While in general I like ticket locks too, the IRQ latency issue still
worries me, and the promised experimental evidence that this is
not an issue won't be able to fully eliminate that reservation. As
already said in response to the v1 posting, while this likely isn't a
primary usage scenario, running Xen itself as a guest of another
hypervisor will (by analogy with what we know about Linux)
immediately be known to be hampered by this. This isn't to say
that I'm opposed to this going in, all I've been trying to point out
is that we're set for another full re-work of spin locks if such a
use case ever became more important to any user of Xen.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel