From owner-svn-src-head@FreeBSD.ORG Wed Oct 31 20:31:53 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9893AED1 for ; Wed, 31 Oct 2012 20:31:53 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id EC1788FC14 for ; Wed, 31 Oct 2012 20:31:52 +0000 (UTC) Received: (qmail 75289 invoked from network); 31 Oct 2012 22:08:16 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 31 Oct 2012 22:08:16 -0000 Message-ID: <50918AAD.2090906@freebsd.org> Date: Wed, 31 Oct 2012 21:31:41 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Ian Lepore Subject: Re: svn commit: r242402 - in head/sys: kern vm References: <201210311807.q9VI7IcX000993@svn.freebsd.org> <1351707964.1120.97.camel@revolution.hippie.lan> <20121031193020.GJ3309@server.rulingia.com> <1351712425.1120.109.camel@revolution.hippie.lan> In-Reply-To: <1351712425.1120.109.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , src-committers@freebsd.org, svn-src-all@freebsd.org, Attilio Rao , svn-src-head@freebsd.org, Peter Jeremy X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 20:31:53 -0000 On 31.10.2012 20:40, Ian Lepore wrote: > On Thu, 2012-11-01 at 06:30 +1100, Peter Jeremy wrote: >> On 2012-Oct-31 18:57:37 +0000, Attilio Rao wrote: >>> On 10/31/12, Adrian Chadd wrote: >>>> Right, but you didn't make it configurable for us embedded peeps who >>>> still care about memory usage. >>> >>> How is this possible without breaking the module/kernel ABI? >> >> Memory usage may override ABI compatibility in an embedded environment. >> >>> All that assuming you can actually prove a real performance loss even >>> in the new cases. >> >> The issue with padding on embedded systems is memory utilisation rather >> than performance. >> > > There are potential performance hits too, in that embedded systems tend > to have tiny caches (16K L1 with no L2, that sort of thing), so > purposely padding things so that large parts of a cache line aren't used > for anything wastes a scarce resource. You can define CACHE_LINE_SIZE to 0 on those platforms. Or to make it even more granular there could be a CACHE_LINE_SIZE_LOCKS that is used for lock padding. -- Andre > That said, I think a point Attilio was trying to make is that we won't > see a large hit because this doesn't affect a large number of mutex > instances. I'm willing to accept his expert advice on that, not in > small part because I'm not sure how I'd go about disputing it. :) > > I'm really busy with $work right now, but things should calm down in a > couple weeks, and I'd be willing to do some measurements on arm systems > then, if I can get some help on how to generate useful data. > > -- Ian > > > >