From owner-svn-src-head@FreeBSD.ORG Thu Nov 1 14:29:49 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 C8C699B for ; Thu, 1 Nov 2012 14:29:49 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2879C8FC0C for ; Thu, 1 Nov 2012 14:29:48 +0000 (UTC) Received: (qmail 79366 invoked from network); 1 Nov 2012 16:06:09 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 1 Nov 2012 16:06:09 -0000 Message-ID: <50928755.6070401@freebsd.org> Date: Thu, 01 Nov 2012 15:29:41 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: attilio@FreeBSD.org Subject: Re: svn commit: r242402 - in head/sys: kern vm References: <201210311807.q9VI7IcX000993@svn.freebsd.org> <50918FEC.3070602@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@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: Thu, 01 Nov 2012 14:29:49 -0000 On 01.11.2012 12:53, Attilio Rao wrote: > On 10/31/12, Andre Oppermann wrote: >> On 31.10.2012 19:10, Attilio Rao wrote: >>> On Wed, Oct 31, 2012 at 6:07 PM, Attilio Rao 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