Thread (8 messages) flat view 8 messages, 3 authors, 2013-01-29

Re: [PATCH 3/3][net-next] gianfar: Pack struct gfar_priv_grp into three cachelines

From: Claudiu Manoil <hidden>
Date: 2013-01-29 15:20:10

On 1/29/2013 4:35 PM, David Laight wrote:
quoted
* 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help