All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: David Ahern <dsahern@gmail.com>, David Miller <davem@davemloft.net>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	David Laight <David.Laight@ACULAB.COM>
Subject: Re: [PATCH net-next v2] net: core: change bool members of struct net_device to bitfield members
Date: Tue, 9 Oct 2018 22:24:58 +0200	[thread overview]
Message-ID: <ded0a778-ca20-4e0f-223d-da3eb5cd71b2@gmail.com> (raw)
In-Reply-To: <35349fe9-94ac-e2d0-f02c-078c9fd58090@gmail.com>

On 09.10.2018 17:20, David Ahern wrote:
> On 10/8/18 2:17 PM, Heiner Kallweit wrote:
>> bool is good as parameter type or function return type, but if used
>> for struct members it consumes more memory than needed.
>> Changing the bool members of struct net_device to bitfield members
>> allows to decrease the memory footprint of this struct.
> 
> What does pahole show for the size of the struct before and after? I
> suspect you have not really changed the size and certainly not the
> actual memory allocated.
> 
> 
Thanks for the hint to use pahole. Indeed we gain nothing,
so there's no justification for this patch.

before:
        /* size: 2496, cachelines: 39, members: 116 */
        /* sum members: 2396, holes: 8, sum holes: 80 */
        /* padding: 20 */
        /* paddings: 4, sum paddings: 19 */
        /* bit_padding: 31 bits */

after:	
        /* size: 2496, cachelines: 39, members: 116 */
        /* sum members: 2394, holes: 8, sum holes: 82 */
        /* bit holes: 1, sum bit holes: 8 bits */
        /* padding: 20 */
        /* paddings: 4, sum paddings: 19 */
        /* bit_padding: 27 bits */

The biggest hole is here, because _tx is annotated to be cacheline-aligned.

        struct hlist_node          index_hlist;          /*   888    16 */

        /* XXX 56 bytes hole, try to pack */

        /* --- cacheline 15 boundary (960 bytes) --- */
        struct netdev_queue *      _tx;                  /*   960     8 */

Reordering the struct members to fill the holes could be a little tricky
and could have side effects because it may make a performance difference
whether certain members are in one cacheline or not.
And whether it's worth to spend this effort (incl. the related risks)
just to save a few bytes (also considering that typically we have quite
few instances of struct net_device)?

  reply	other threads:[~2018-10-10  3:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-08 20:17 [PATCH net-next v2] net: core: change bool members of struct net_device to bitfield members Heiner Kallweit
2018-10-09 15:20 ` David Ahern
2018-10-09 20:24   ` Heiner Kallweit [this message]
2018-10-09 20:43     ` David Ahern
2018-10-09 20:52     ` Eric Dumazet
2018-10-10  8:59       ` David Laight

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=ded0a778-ca20-4e0f-223d-da3eb5cd71b2@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=netdev@vger.kernel.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.