pahole - Finding holes in kernel structs

[Brooks Davis]

On Thu, Feb 12, 2009 at 05:54:24PM +0100, Max Laier wrote:
> 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.

Remember however, that any structure that is exposed to userland can't
just be changed.  If it's part a syscall interface then the old layout
must be supported.  If that's going to be done, it's worth showing an
actual, measurable improvement before writing the compatibility code.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090212/0d77610b/attachment.pgp