pahole - Finding holes in kernel structs

[Sam Leffler]

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.

    Sam