Date: Wed, 31 Oct 2012 21:54:04 +0100 From: Andre Oppermann <andre@freebsd.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: <50918FEC.3070602@freebsd.org> 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 31.10.2012 19:10, 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. I'd say for an rwlock you can make it unconditional. The very purpose of it is to be aquired by multiple CPU's causing cache line dirtying for every concurrent reader. Rwlocks are only ever used because multiple concurrent readers are expected. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50918FEC.3070602>