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
pgpTybPsAyL0f.pgp
Description: PGP signature
