Date: Thu, 12 Feb 2009 11:01:19 -0600 From: Brooks Davis <brooks@freebsd.org> To: Max Laier <max@love2party.net> Cc: freebsd-hackers@freebsd.org, Sam Leffler <sam@freebsd.org>, Andrew Brampton <brampton+freebsd-hackers@gmail.com> Subject: Re: pahole - Finding holes in kernel structs Message-ID: <20090212170119.GA7951@lor.one-eyed-alien.net> In-Reply-To: <200902121754.24536.max@love2party.net> References: <d41814900902120608i4b54c86fp9f565bbeead5a476@mail.gmail.com> <200902121717.47841.max@love2party.net> <4994516B.8060703@freebsd.org> <200902121754.24536.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 thi= nk > > >> many of my patches would be accepted? > > >> > > >> 2) Is there a way to find out the most heavily used structs? There a= re > > >> ~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 i= s 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 lo= ok > > > 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. >=20 > Let's not be too "glass half empty" about it, though. The same is true i= n the=20 > opposite direction. If we can identify and eliminate an unnecessary hole= in=20 > an important structure we might gain that same performance just by reshuf= fling=20 > 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 --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJlFXeXY6L6fI4GtQRAnSLAJ9G+i+7RJgY8FTkpq8itACSuPG9GgCfQdwV dWgA09bSR2xoZpaEM3+Xjd4= =8qBf -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090212170119.GA7951>