Date: Thu, 12 Feb 2009 08:42:19 -0800 From: Sam Leffler <sam@freebsd.org> To: Max Laier <max@love2party.net> Cc: freebsd-hackers@freebsd.org, Andrew Brampton <brampton+freebsd-hackers@gmail.com> Subject: Re: pahole - Finding holes in kernel structs Message-ID: <4994516B.8060703@freebsd.org> In-Reply-To: <200902121717.47841.max@love2party.net> References: <d41814900902120608i4b54c86fp9f565bbeead5a476@mail.gmail.com> <200902121717.47841.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4994516B.8060703>