From owner-svn-src-all@FreeBSD.ORG Wed Oct 31 20:54:10 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD13DC8D for ; Wed, 31 Oct 2012 20:54:10 +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 1A6D48FC0A for ; Wed, 31 Oct 2012 20:54:09 +0000 (UTC) Received: (qmail 75406 invoked from network); 31 Oct 2012 22:30:39 -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 ; 31 Oct 2012 22:30:39 -0000 Message-ID: <50918FEC.3070602@freebsd.org> Date: Wed, 31 Oct 2012 21:54:04 +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> 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-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 20:54:10 -0000 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. -- Andre