From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 17:02:35 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B1A9106564A; Thu, 12 Feb 2009 17:02:35 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 4691B8FC18; Thu, 12 Feb 2009 17:02:34 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n1CH1Jds014153; Thu, 12 Feb 2009 11:01:19 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n1CH1JkT014152; Thu, 12 Feb 2009 11:01:19 -0600 (CST) (envelope-from brooks) Date: Thu, 12 Feb 2009 11:01:19 -0600 From: Brooks Davis To: Max Laier Message-ID: <20090212170119.GA7951@lor.one-eyed-alien.net> References: <200902121717.47841.max@love2party.net> <4994516B.8060703@freebsd.org> <200902121754.24536.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline In-Reply-To: <200902121754.24536.max@love2party.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Thu, 12 Feb 2009 11:01:19 -0600 (CST) Cc: freebsd-hackers@freebsd.org, Sam Leffler , Andrew Brampton Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 17:02:35 -0000 --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--