Date: Thu, 01 Nov 2012 15:29:41 +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: <50928755.6070401@freebsd.org> In-Reply-To: <CAJ-FndD6FVj9X-ZDOLn4yMMv_5tT7EZj0ZCu7ADy5ho_7%2BK2uw@mail.gmail.com> References: <201210311807.q9VI7IcX000993@svn.freebsd.org> <CAJ-FndDRkBS57e9mzZoJWX5ugJ0KBGxhMSO50KB8Wm8MFudjCA@mail.gmail.com> <50918FEC.3070602@freebsd.org> <CAJ-FndD6FVj9X-ZDOLn4yMMv_5tT7EZj0ZCu7ADy5ho_7%2BK2uw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01.11.2012 12:53, Attilio Rao wrote: > On 10/31/12, Andre Oppermann <andre@freebsd.org> wrote: >> 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. > > I thought about it, but I think the same arguments as for mutexes remains. > The real problem is that having default rwlocks pad-aligned will put > showstoppers for their usage in sensitive structures. For example, I > have plans to use them in vm_object at some point to replace > VM_OBJECT_LOCK and I do want to avoid the extra-bloat for such > structures. > > Also, please keep in mind that there is no direct relation between > "read acquisition" and "high contention" with the latter being the > real reason for having pad-aligned locks. I do not agree. If there is no contention then there is no need for a rwlock, a normal mutex would be sufficient. A rwlock is used when multiple concurrent readers are expected. Each read lock and unlock dirties the cache line for all other CPU's. Please note that I don't want to prevent you from doing the work all over for rwlocks. It's just that the use case for a non-padded rwlock is very narrow. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50928755.6070401>