pahole - Finding holes in kernel structs

[Max Laier]

On Thursday 12 February 2009 17:42:19 Sam Leffler wrote:
> Max Laier wrote:
> > On Thursday 12 February 2009 15:08:22 Andrew Brampton wrote:
> >> So I ran the tool pahole over a 7.1 FreeBSD Kernel, and found that
> >> many of the struct had holes, and some of which could be rearranged to
> >> fill the gap.
> >
> > Interesting tool ...
>
> Someone should be able to do the same thing with coverity but it's
> obviously less effort to use something that exists.  If I recall this
> and related tools like sparse use dwarf symbols which we don't generate
> by default.  But with dtrace support I think we now can in fact generate
> the symbols easily so maybe someone can look at porting the tools...
>
> >>               I've made the list available here[2]. So my questions
> >> are two fold:
> >>
> >> 1) Is it worth my time trying to rearrange structs? If so do you think
> >> many of my patches would be accepted?
> >>
> >> 2) Is there a way to find out the most heavily used structs? There are
> >> ~3600 structs, and ~2000 holes, it might be a waste of my time fixing
> >> the structs which are only used once.
> >
> > That's the tricky part.  Rearranging the structs itself is not that
> > difficult, but identifying which should be rearranged and if, how ...
> > that's the problem. The fact that gaps might be different for 64 vs. 32
> > bit architectures has already been mentioned.
> >
> > In addition one needs to keep in mind that changing a struct layout is a
> > ABI change.  So if we do identify structs that we want to change we
> > should do them all at once to keep the different versions down to a
> > minimum.
> >
> > So to answer your first question, submitting 101 patches to rearrange 101
> > structs is certainly a wasted effort.  However, if you take a good look
> > at the 2000 holes, identify an interesting subset and submit a patch to
> > fix that subset ... that would be a worthwhile effort ... IMHO.
>
> The other thing to keep in mind is that structure layout can have a
> noticeable effect on cache locality.  Arbitrarily rearranging structure
> members can generate many more cache misses so one should sanity check
> changes w/ something like hwpmc.  However as noted because layout may be
> platform-dependent even if something shows no change on x86 it may be a
> loss on another architecture and finding that performance drop may be
> really hard.

Let's not be too "glass half empty" about it, though.  The same is true in the 
opposite direction.  If we can identify and eliminate an unnecessary hole in 
an important structure we might gain that same performance just by reshuffling 
a few lines.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News