From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 11:23:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C07C51065670 for ; Wed, 5 Jan 2011 11:23:03 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 46A8B8FC0C for ; Wed, 5 Jan 2011 11:23:02 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PaRSH-0002IJ-Bn for freebsd-current@freebsd.org; Wed, 05 Jan 2011 12:23:01 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Jan 2011 12:23:01 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Jan 2011 12:23:01 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 05 Jan 2011 12:22:50 +0100 Lines: 46 Message-ID: References: <20110104185930.GA62775@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <20110104185930.GA62775@freebsd.org> X-Enigmail-Version: 1.1.2 Subject: Re: [RFC]: unnecessary padding in various kernel structures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 11:23:03 -0000 On 04/01/2011 19:59, Roman Divacky wrote: > hi, > > clang (svn version) has ability to detect unnecessary padding in structures. > > I ran this on kernel build on i386 (stripped GENERIC) and amd64 (full GENERIC), > preprocessed this and posted on web. > > The lists contain the file of the definition, name of the structure, size of > the unnecessary padding and reason for the alignment. The last field is > how many times this was hit during the build of the kernel. It looks like "padding... to alignment boundary" means "because of struct {...} __aligned(CACHE_LINE_SIZE)" and such, and we cannot run away from those - maybe you should filter those results out? > The lists are sorted by the size of the padding. > > Examples (i386): > > dev/usb/controller/ohci.h:64:8: 2 times > padding size of 'struct ohci_hcca' with 120 bytes to alignment boundary > sys/pcpu.h:156:8: 58 times > padding size of 'struct pcpu' with 108 bytes to alignment boundary > sys/pcpu.h:199:2: 58 times > padding struct 'struct pcpu' with 84 bytes to align 'pc_monitorbuf' > dev/usb/controller/ehci.h:170:8: 1 times > padding size of 'struct ehci_qtd' with 58 bytes to alignment boundary > kern/sched_ule.c:206:8: 1 times > padding size of 'struct tdq' with 41 bytes to alignment boundary > > Examples(amd64): > > net/flowtable.c:179:11: 1 times > padding struct 'struct flowtable' with 124 bytes to align 'ft_udp_idle' > dev/usb/controller/ohci.h:64:8: 2 times > padding size of 'struct ohci_hcca' with 120 bytes to alignment boundary > net/flowtable.c:160:8: 1 times > padding size of 'struct flowtable' with 108 bytes to alignment boundary > vm/uma_int.h:184:8: 6 times > padding size of 'struct uma_cache' with 96 bytes to alignment boundary > vm/uma_int.h:338:19: 5 times > padding struct 'struct uma_zone' with 92 bytes to align 'uz_cpu' > net/flowtable.c:149:8: 1 times > padding size of 'struct flowtable_stats' with 64 bytes to alignment boundary