From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 16:54:26 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 478F61065675 for ; Thu, 12 Feb 2009 16:54:26 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.freebsd.org (Postfix) with ESMTP id E06998FC1D for ; Thu, 12 Feb 2009 16:54:25 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-026-076.pools.arcor-ip.net [88.66.26.76]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1LXepV0Bi8-00012F; Thu, 12 Feb 2009 17:54:25 +0100 Received: (qmail 33260 invoked from network); 12 Feb 2009 16:54:24 -0000 Received: from fbsd8.laiers.local (192.168.4.200) by ns1.laiers.local with SMTP; 12 Feb 2009 16:54:24 -0000 From: Max Laier Organization: FreeBSD To: freebsd-hackers@freebsd.org Date: Thu, 12 Feb 2009 17:54:24 +0100 User-Agent: KMail/1.10.4 (FreeBSD/8.0-CURRENT; KDE/4.1.4; i386; ; ) References: <200902121717.47841.max@love2party.net> <4994516B.8060703@freebsd.org> In-Reply-To: <4994516B.8060703@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902121754.24536.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19Pq6d11gbo29w1WJHvVM02ZJdSecYi7XkJX5R m85kfUfOtAZM+trnYQR40S4dPLsVC8ASuEXX0Ph5rQ4TJI0AOc XzJRKqRmUWyqbOt/aVd9w== Cc: 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 16:54:27 -0000 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. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News