From owner-svn-src-all@FreeBSD.ORG Thu Oct 25 04:41:17 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03C32C3; Thu, 25 Oct 2012 04:41:17 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id 870868FC08; Thu, 25 Oct 2012 04:41:16 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q9P4f7ug027280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Oct 2012 15:41:14 +1100 Date: Thu, 25 Oct 2012 15:41:06 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andre Oppermann Subject: Re: svn commit: r242014 - head/sys/kern In-Reply-To: <50889EE0.8030105@freebsd.org> Message-ID: <20121025145158.R999@besplex.bde.org> References: <201210241836.q9OIafqo073002@svn.freebsd.org> <201210241443.25988.jhb@freebsd.org> <50884E9F.3090706@freebsd.org> <508855DA.1080903@freebsd.org> <50889EE0.8030105@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@FreeBSD.org, John Baldwin , svn-src-all@FreeBSD.org, attilio@FreeBSD.org, svn-src-head@FreeBSD.org, Jim Harris X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 04:41:17 -0000 On Thu, 25 Oct 2012, Andre Oppermann wrote: > ... > I spoke too soon. Attilio is completely right in his assessment. > > It does work when done on the struct definition: > > struct mtx { > ... > } __aligned(CACHE_LINE_SIZE); /* works including .bss alignment & padding > */ > > When creating a struct (in globals at least) it doesn't work: > > struct mtx __aligned(CACHE_LINE_SIZE) foo_mtx; /* doesn't work */ > >> It seems to come down to either a) fixing gcc+ld; or b) hacking >> around it by magically padding the structs that require it. > > The question now becomes of whether we can (should?) make the latter > case above work or find another workaround. The latter case already works correctly. The alignment directive only specifies the alignment requirement for the start of the object. The size of the object is whatever it is, and there is no directive for padding. Consider an array of objects: struct mtx __aligned(CACHE_LINE_SIZE) foo_mtx[128]; This aligns the first element in the array. There is no way that it can do special alignment for other elements. The elements must follow each other, with no padding in between. The struct size is whatever it is and is already padded for the correct alignment as known at the time of the struct declaration, and you can't change its size later. I once wrote the following mistake which gave excessive alignment, but also sort or what you want: static double __aligned(64) P1 = ..., P2 = ..., P3 = ...; This was intended to align the first double to 64 bytes and have the others follow with no padding, much like what would happen if the variables were in an array (they are named Pn mainly because this looks nicer than P[n]). What it actually does is align all the variables to 64 bytes and waste a lot of space and cache resources. The linker might fill in the gaps, but at least with static variables in a small program, it won't be able to find enough variables to fill them all. With static variables in a large program, dummy variables could probably be provided to fill in the gaps. For global mutexes, I would try putting them all in the same struct starting at a page boundary, a bit like pcpu, so that I can control the layout of them all. Bruce