netdev - Re: [PATCH 3/3][net-next] gianfar: Pack struct gfar_priv

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 29 Jan 2013 17:19:47 +0200
From:	Claudiu Manoil <claudiu.manoil@...escale.com>
To:	David Laight <David.Laight@...LAB.COM>
CC:	<netdev@...r.kernel.org>, "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH 3/3][net-next] gianfar: Pack struct gfar_priv_grp into
 three cachelines

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



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html