Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 31 Oct 2012 12:26:04 -0600
From:      Ian Lepore <freebsd@damnhippie.dyndns.org>
To:        attilio@freebsd.org
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r242402 - in head/sys: kern vm
Message-ID:  <1351707964.1120.97.camel@revolution.hippie.lan>
In-Reply-To: <CAJ-FndDRkBS57e9mzZoJWX5ugJ0KBGxhMSO50KB8Wm8MFudjCA@mail.gmail.com>
References:  <201210311807.q9VI7IcX000993@svn.freebsd.org> <CAJ-FndDRkBS57e9mzZoJWX5ugJ0KBGxhMSO50KB8Wm8MFudjCA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2012-10-31 at 18:10 +0000, Attilio Rao wrote:
> On Wed, Oct 31, 2012 at 6:07 PM, Attilio Rao <attilio@freebsd.org> wrote:
> > Author: attilio
> > Date: Wed Oct 31 18:07:18 2012
> > New Revision: 242402
> > URL: http://svn.freebsd.org/changeset/base/242402
> >
> > Log:
> >   Rework the known mutexes to benefit about staying on their own
> >   cache line in order to avoid manual frobbing but using
> >   struct mtx_padalign.
> 
> Interested developers can now dig and look for other mutexes to
> convert and just do it.
> Please, however, try to enclose a description about the benchmark
> which lead you believe the necessity to pad the mutex and possibly
> some numbers, in particular when the lock belongs to structures or the
> ABI itself.
> 
> Next steps involve porting the same mtx(9) changes to rwlock(9) and
> port pvh global pmap lock to rwlock_padalign.
> 
> Thanks,
> Attilio
> 
> 

Doesn't this padding to cache line size only help x86 processors in an
SMP kernel?  I was expecting to see some #ifdef SMP so that we don't pay
a big price for no gain in small-memory ARM systems and such.  But maybe
I'm misunderstanding the reason for the padding.

-- Ian





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1351707964.1120.97.camel>