From owner-svn-src-head@FreeBSD.ORG Thu Nov 1 20:31:23 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 DD73C3A8; Thu, 1 Nov 2012 20:31:23 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 89B7E8FC08; Thu, 1 Nov 2012 20:31:22 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so2706402lag.13 for ; Thu, 01 Nov 2012 13:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vE+eIL9RyJ+KDZ3CngnIHmSOg5Faq1qA/DVHBImzFgQ=; b=t6LRj7rBv7i2vCE/wWUJr+MW2e4aOYzelVXupj1GzzXcEM0O7qG66R8H9NXyWhMrx7 2j4tLjcouCEWL2J2pp3DNv3YnEYIZCCJGVv+97DixRvez9DL9Ou2ho4Kbq+3giC3vA1H +ERDtmgvxmSkymftoZyyzXkl1Gc3XXXA7RTdWudtbWbrTxkiBr1EkdjP76+CCVCXj+KI uyIQ74SojwsqnHlJfdUQBX7RrH8OWPeOit7yMM6qNm8RoI3FIPEZ/bbhpdh6FXW0m2Ul FW0fLjJ3okCknGAZIr1YRDvQCYD135bn2woT4LNCsaHEN7NFxvHfdLOFFRh1qHQ4UpQx svXg== MIME-Version: 1.0 Received: by 10.152.129.197 with SMTP id ny5mr35929718lab.43.1351801881206; Thu, 01 Nov 2012 13:31:21 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.30.37 with HTTP; Thu, 1 Nov 2012 13:31:21 -0700 (PDT) In-Reply-To: <50928755.6070401@freebsd.org> References: <201210311807.q9VI7IcX000993@svn.freebsd.org> <50918FEC.3070602@freebsd.org> <50928755.6070401@freebsd.org> Date: Thu, 1 Nov 2012 20:31:21 +0000 X-Google-Sender-Auth: TREdQCsd3hok_p3TVX_VSMk7_cY Message-ID: Subject: Re: svn commit: r242402 - in head/sys: kern vm From: Attilio Rao To: Andre Oppermann , Jeff Roberson Content-Type: text/plain; charset=UTF-8 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 Reply-To: attilio@FreeBSD.org 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 20:31:23 -0000 On 11/1/12, Andre Oppermann wrote: > 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. 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