All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: Tim Deegan <tim@xen.org>, Jan Beulich <jbeulich@suse.com>
Cc: keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com,
	jennifer.herbert@citrix.com, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCHv3 3/4] xen: use ticket locks for spin locks
Date: Thu, 30 Apr 2015 12:55:07 +0100	[thread overview]
Message-ID: <5542181B.2020806@citrix.com> (raw)
In-Reply-To: <20150430100932.GB13575@deinos.phlegethon.org>

On 30/04/15 11:09, Tim Deegan wrote:
> At 00:56 +0100 on 30 Apr (1430355366), Jan Beulich wrote:
>>>>> David Vrabel <david.vrabel@citrix.com> 04/29/15 5:28 PM >>>
>>> On 29/04/15 00:15, Jan Beulich wrote:
>>>>>>> David Vrabel <david.vrabel@citrix.com> 04/28/15 6:16 PM >>>
>>>>> 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.
>>
>> Odd - this suggests there's still some 64-byte alignment somewhere, but I
>> can't immediately spot it. Only struct vcpu has an obvious 64-byte aligned
>> field (struct pi_desc) afaics.
> 
> I got slightly different numbers to David (I suspect just starting
> from a different baseline) but the biggest hole came from struct
> arch_domain being __cacheline_aligned (i.e. 128-byte aligned).
> 
> There are some holes above it in struct domain which should pack in
> nicely to counteract the larger spinlocks, e.g. this was enough to
> naturally align arch_domain again in my tree:
> 
> @@ -334,9 +334,9 @@ struct domain
>      spinlock_t       rangesets_lock;
>  
>      /* Event channel information. */
> +    unsigned int     max_evtchns;
>      struct evtchn   *evtchn;                         /* first bucket only */
>      struct evtchn  **evtchn_group[NR_EVTCHN_GROUPS]; /* all other buckets */
> -    unsigned int     max_evtchns;
>      unsigned int     max_evtchn_port;
>      spinlock_t       event_lock;
>      const struct evtchn_port_ops *evtchn_port_ops;

This change makes struct domain 8 bytes bigger with ticket locks.

On x86 there are 12 spinlocks in struct domain which is 48 bytes extra.
 I've clawed back 16 bytes by repacking struct paging_domain and struct
hvm_domain.

David

  reply	other threads:[~2015-04-30 11:55 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-21 10:11 [PATCHv3 0/4] Use ticket locks for spinlocks David Vrabel
2015-04-21 10:11 ` [PATCHv3 1/4] x86: provide xadd() David Vrabel
2015-04-21 10:36   ` Jan Beulich
2015-04-21 12:36     ` David Vrabel
2015-04-21 13:12       ` Jan Beulich
2015-04-21 13:15         ` David Vrabel
2015-04-21 13:20           ` Jan Beulich
2015-04-21 10:11 ` [PATCHv3 2/4] arm: " David Vrabel
2015-04-21 10:11 ` [PATCHv3 3/4] xen: use ticket locks for spin locks David Vrabel
2015-04-23 11:58   ` Jan Beulich
2015-04-28 15:56     ` David Vrabel
2015-04-28 23:15       ` Jan Beulich
2015-04-29 15:21         ` David Vrabel
2015-04-29 23:56           ` Jan Beulich
2015-04-30 10:09             ` Tim Deegan
2015-04-30 11:55               ` David Vrabel [this message]
2015-04-23 12:03   ` Tim Deegan
2015-04-23 13:43     ` David Vrabel
2015-04-23 13:45       ` Andrew Cooper
2015-04-23 14:58         ` Tim Deegan
2015-04-23 14:24       ` Tim Deegan
2015-04-23 14:51         ` Tim Deegan
2015-04-23 13:54     ` Jan Beulich
2015-04-23 14:43       ` Tim Deegan
2015-04-23 14:58         ` Jan Beulich
2015-04-29 15:36           ` David Vrabel
2015-04-29 16:56             ` Tim Deegan
2015-04-29 17:00               ` David Vrabel
2015-04-30  9:00                 ` Tim Deegan
2015-04-29 23:48             ` Jan Beulich
2015-04-21 10:11 ` [PATCHv3 4/4] x86, arm: remove asm/spinlock.h from all architectures David Vrabel
2015-04-21 10:22 ` [PATCHv3 0/4] Use ticket locks for spinlocks Jan Beulich
2015-04-21 11:24   ` Jennifer Herbert
2015-04-23 12:42   ` David Vrabel
2015-04-30 15:44     ` David Vrabel
2015-05-04  7:18       ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5542181B.2020806@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jennifer.herbert@citrix.com \
    --cc=keir@xen.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.