From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 17:55:10 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 5356C10656C8; Thu, 12 Feb 2009 17:55:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2C1088FC13; Thu, 12 Feb 2009 17:55:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id C110346B53; Thu, 12 Feb 2009 12:55:09 -0500 (EST) Date: Thu, 12 Feb 2009 17:55:09 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Max Laier In-Reply-To: <200902121754.24536.max@love2party.net> Message-ID: References: <200902121717.47841.max@love2party.net> <4994516B.8060703@freebsd.org> <200902121754.24536.max@love2party.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Sam Leffler , Andrew Brampton , Joseph Koshy 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:55:11 -0000 On Thu, 12 Feb 2009, Max Laier wrote: >>> 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. Well, I think we want to inform this through actual measurement. Right now, tools like hwpmc track cache misses by point in executable code, but what would be nice is if we could post-process to generate cache miss information by data structure field... Robert N M Watson Computer Laboratory University of Cambridge