netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Claudiu Manoil <claudiu.manoil@freescale.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: <netdev@vger.kernel.org>, "David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH 3/3][net-next] gianfar: Pack struct gfar_priv_grp into three cachelines
Date: Tue, 29 Jan 2013 17:19:47 +0200	[thread overview]
Message-ID: <5107E893.9030706@freescale.com> (raw)
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7124@saturn3.aculab.com>

On 1/29/2013 4:35 PM, David Laight wrote:
>> * remove unused members(!): imask, ievent
>> * move space consuming interrupt name strings (int_name_* members) to
>> external structures, unessential for the driver's hot path
>> * keep high priority hot path data within the first 2 cache lines
>>
>> This reduces struct gfar_priv_grp from 6 to 3 cache lines.
>
> Does it really matter where the message texts are allocated?
> Provided they aren't intermixed with the 'hot' data.
> Allocating them separately just seems over complicated.
>
> 	David
>

Hello David,

I think that the size of 'struct gfar_priv_grp' matters because we have
struct gfar_private {
	...
	struct gfar_priv_grp gfargrp[2];
	...
}
which in turn will be bloated by an unnecessarily large gfar_priv_grp.
gfar_private also contains a fair number of runtime critical members
(including gfargrp) and we want those members to fit into as few
cachelines as possible too. Also, it would be wasteful to have memory
holes inside struct gfar_priv_grp, in this context, and the current
patch resolves those memory holes, by compacting this structure to
exactly 96 bytes.

I don't find this change over complicated, but I'm open to suggestions
on where to move those message texts, outside of gfar_priv_grp (or
other runtime critical structure).

Thanks,
Claudiu

  reply	other threads:[~2013-01-29 15:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-29 13:55 [PATCH 1/3][net-next] gianfar: Optimize struct gfar_priv_tx_q for two cache lines Claudiu Manoil
2013-01-29 13:55 ` [PATCH 2/3][net-next] gianfar: Cleanup gfar_parse_group() code Claudiu Manoil
2013-01-29 13:55   ` [PATCH 3/3][net-next] gianfar: Pack struct gfar_priv_grp into three cachelines Claudiu Manoil
2013-01-29 14:35     ` David Laight
2013-01-29 15:19       ` Claudiu Manoil [this message]
2013-01-29 20:22     ` David Miller
2013-01-29 20:22   ` [PATCH 2/3][net-next] gianfar: Cleanup gfar_parse_group() code David Miller
2013-01-29 20:22 ` [PATCH 1/3][net-next] gianfar: Optimize struct gfar_priv_tx_q for two cache lines David Miller

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=5107E893.9030706@freescale.com \
    --to=claudiu.manoil@freescale.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=davem@davemloft.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).