From owner-svn-src-all@FreeBSD.ORG Thu Nov 1 11:53:58 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 40FE415A; Thu, 1 Nov 2012 11:53:58 +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 166AD8FC16; Thu, 1 Nov 2012 11:53:56 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so2224754lag.13 for ; Thu, 01 Nov 2012 04:53:55 -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=eBiDGbmdEblKpbypZdVhbRj23WeMKNrdKCB52MSdhXI=; b=diIc4As7vuDzHXTZifCiG0jpbuNGL6SdJr1PW8EMsWTkXGpLTVwJsiV2tQ9u9ByCyw Nwm530RhZtcklYv7QO4xueg7iBCSN3cRphSagvIOKO1jWgeIBFPGqZuExJcTvHnoiZ3Q uWoIsj7LSr/0elel26m3tAXM9kd+DFEt5JiiA7V0pWLdl5y0uBiLFzW/e0sX9+/3D7kS wROC21mJqqDTVvGgZnkHNDuvPnCzo64oTWgvuy7zWKonMa90JdaBNBCSQ+IuYEffs2KV Vi7sjWZ+WFbHJ/iKHgkErFpFOQn5Eut2ycvioejrYWgzA+ZUZteHFALZ/Q4jk5mpvOFR N6xQ== MIME-Version: 1.0 Received: by 10.152.110.234 with SMTP id id10mr14469547lab.15.1351770835426; Thu, 01 Nov 2012 04:53:55 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.30.37 with HTTP; Thu, 1 Nov 2012 04:53:55 -0700 (PDT) In-Reply-To: <50918FEC.3070602@freebsd.org> References: <201210311807.q9VI7IcX000993@svn.freebsd.org> <50918FEC.3070602@freebsd.org> Date: Thu, 1 Nov 2012 11:53:55 +0000 X-Google-Sender-Auth: GND0Z4KyMdgcWcjZFwPNW7OTfF0 Message-ID: Subject: Re: svn commit: r242402 - in head/sys: kern vm From: Attilio Rao To: Andre Oppermann 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-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org 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: Thu, 01 Nov 2012 11:53:58 -0000 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. Attilio -- Peace can only be achieved by understanding - A. Einstein