From owner-svn-src-head@FreeBSD.ORG Wed Oct 31 19:40:42 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 27124E2D; Wed, 31 Oct 2012 19:40:42 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 1DB428FC08; Wed, 31 Oct 2012 19:40:28 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q9VJeSC3013412; Wed, 31 Oct 2012 13:40:28 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q9VJePej006844; Wed, 31 Oct 2012 13:40:26 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: svn commit: r242402 - in head/sys: kern vm From: Ian Lepore To: Peter Jeremy In-Reply-To: <20121031193020.GJ3309@server.rulingia.com> References: <201210311807.q9VI7IcX000993@svn.freebsd.org> <1351707964.1120.97.camel@revolution.hippie.lan> <20121031193020.GJ3309@server.rulingia.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Oct 2012 13:40:25 -0600 Message-ID: <1351712425.1120.109.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Attilio Rao , svn-src-head@freebsd.org, Adrian Chadd , src-committers@freebsd.org, svn-src-all@freebsd.org 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 19:40:42 -0000 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. 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