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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
