On 16/04/15 13:03, Tim Deegan wrote:
>
>> +static int __spin_is_locked(spinlock_t *lock)
>> +{
>> +return lock->tickets.head != lock->tickets.tail;
>> +}
>
> Maybe atomic_read the lock and do the comparison on the local value?
> Just from an abundance of caution - can't think of an obvious re
>>> On 16.04.15 at 14:03, 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 val
At 13:46 +0100 on 16 Apr (1429192004), David Vrabel wrote:
> On 16/04/15 13:03, Tim Deegan wrote:
> >
> > Should there be a follow-up patch that removes all the arch-specific
> > raw_spinlock_t stuff? Or is it still in use somewhere else?
>
> This is patch #6.
So it is. /me needs an eye test.
On 16/04/15 13:03, Tim Deegan wrote:
>
> Should there be a follow-up patch that removes all the arch-specific
> raw_spinlock_t stuff? Or is it still in use somewhere else?
This is patch #6.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
ht
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
