Date: Thu, 1 Nov 2012 20:31:21 +0000 From: Attilio Rao <attilio@freebsd.org> To: Andre Oppermann <andre@freebsd.org>, Jeff Roberson <jeff@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: <CAJ-FndDYN6j0xVZx_d1SEvGcKccmQJ6=FVUU-XoYPja9gv4qbQ@mail.gmail.com> In-Reply-To: <50928755.6070401@freebsd.org> References: <201210311807.q9VI7IcX000993@svn.freebsd.org> <CAJ-FndDRkBS57e9mzZoJWX5ugJ0KBGxhMSO50KB8Wm8MFudjCA@mail.gmail.com> <50918FEC.3070602@freebsd.org> <CAJ-FndD6FVj9X-ZDOLn4yMMv_5tT7EZj0ZCu7ADy5ho_7%2BK2uw@mail.gmail.com> <50928755.6070401@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/1/12, Andre Oppermann <andre@freebsd.org> wrote: > 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. So here is the patch for adding the decoupling infrastructure to rwlock and add the padalign type: http://www.freebsd.org/~attilio/rwlock_decoupled_padalign.patch I've tested by converting some rwlocks in the system and everything looks good to me. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndDYN6j0xVZx_d1SEvGcKccmQJ6=FVUU-XoYPja9gv4qbQ>