From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 22:05:43 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 8A7DA106566B for ; Thu, 12 Feb 2009 22:05:43 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id 688968FC16 for ; Thu, 12 Feb 2009 22:05:43 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from zeno.ucsd.edu (zeno.ucsd.edu [132.239.145.22]) by euclid.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n1CM5bo09672; Thu, 12 Feb 2009 14:05:37 -0800 (PST) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n1CM5bV04513; Thu, 12 Feb 2009 14:05:37 -0800 (PST) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Thu, 12 Feb 2009 14:05:37 -0800 (PST) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: Marcel Moolenaar In-Reply-To: Message-ID: References: <200902121549.n1CFnLdt002361@fire.js.berklix.net> <49944F8F.5080104@quis.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Julian Stacey , Jille Timmermans , 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 22:05:44 -0000 On Thu, 12 Feb 2009, Marcel Moolenaar wrote: > > On Feb 12, 2009, at 8:34 AM, Jille Timmermans wrote: > >> Julian Stacey schreef: >>>> 1) Is it worth my time trying to rearrange structs? >>> I wondered whether as a sensitivity test, some version of gcc (or >>> its competitor ?) might have capability to automatically re-order >>> variables ? but found nothing in man gcc "Optimization Options". >> There is a __packed attribute, I don't know what it exactly does and >> whether it is an improvement. >> > > __packed is always a gross pessimization. The side-effect of > packing a structure is that the alignment of the structure > drops to 1. That means that any field will be read 1 byte at > a time and reconstructed by logical operations. The other alternative is to read/write that member by unaligned operations, on platforms that support it. This also typically comes with a performance penalty, of course. Usually it means the hardware reads the two words that overlap the member and pieces it back together. But on such a platform the software does not need to handle it specially; it executes the same instruction, but it takes more time. The only reason to use this would be (1) if you needed to have your structure occupy as little memory as possible; for instance, if your structure had two elements, one 'int' and one 'char', and you had 1 billion of them, using __packed__ would save you 3 gigabytes. Or (2) if you need to conform to an externally defined data structure that already does this. Most places in the kernel, I don't think either of these would be true. -- Nate Eldredge neldredge@math.ucsd.edu