Re: [Xen-devel] [PATCHv3 3/4] xen: use ticket locks for spin locks

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 29/04/15 00:15, Jan Beulich wrote:
>>>> David Vrabel <david.vrabel@xxxxxxxxxx> 04/28/15 6:16 PM >>>
>> On 23/04/15 12:58, Jan Beulich wrote:
>>>> +typedef union {
>>>> +    u32 head_tail;
>>>> +    struct {
>>>> +        u16 head;
>>>> +        u16 tail;
>>>> +    };
>>>> +} spinlock_tickets_t;
>>>> +
>>>>  typedef struct spinlock {
>>>> -    raw_spinlock_t raw;
>>>> +    spinlock_tickets_t tickets;
>>>
>>> At least for x86 this means a growth of this and hence various
>>> other structures - did you examine the effects thereof? Of
>>> course otoh getting the lock size uniform across architectures
>>> is a good thing.
>>
>> I've not looked.
>>
>> Are there any structures whose size you're particularly concerned about?
> 
> No specific ones (but of course structures with an inherent size constraint
> - like struct domain and struct vcpu - are, with all of their sub-structures,
> primary candidates). I just recall that in some cases (and this may no longer
> apply due to later additions) structures got arranged specifically taking in
> mind the 2-byte size of the locks, and the growth here may thus mean a
> structure size growth of more than just two bytes.

Spin locks are currently 4 bytes (2 bytes for the lock, plus 2 bytes for
the recurse_{cnt,cpu}), and ticket locks are now 8 bytes (an increase in
4 bytes).

struct vcpu does not increase in size (there is 56, now 48 bytes, of
padding before the arch field).

struct domain increases from 3480 to 3544 bytes.

There's no change to any event channel structure.

struct grant_table increases from 64 to 74 bytes, but in combination
with the pending grant table locking patches this can be made 64 bytes
again.

David

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