From owner-svn-src-head@FreeBSD.ORG Wed Oct 31 23:42:13 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 A194D606; Wed, 31 Oct 2012 23:42:13 +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 4EF3D8FC0C; Wed, 31 Oct 2012 23:42:11 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so1841933lag.13 for ; Wed, 31 Oct 2012 16:42:11 -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=BhXYQVGz4bkfnOTwPhbvEoQTtb8KVZ5cLOWYlAu3ZEs=; b=LI+Uxy4m2TdweV4sEFRmkNUm7btxz4f/i+zImyZXsFr4L6mONGfhcdyVuaIpksrK+y 9h1zL7Zd/nQaYHV2HC5sKmi7eQfLiAMt/mmwFRJCIsBx1/McfqgcRbHE66vlLotk8bNL vTwRPsYVOjfGMMjzQI532yod3P7JzesF676ATtrRqN1c4TrxYCTlPqdccnyK/bTnPiYw neZ15pd1bcaZ2aOROEorgzUnKxCU7erDO2aT0NHEf5jvsjV2o8hWdD55UkFroThPnooN fxWSez1EW4BxG0aO6GD9NKHw+N6Mwei0/DernwnbfD+jNIeU2Q7dvciAqW6WAG0l9Zpo 6lqg== MIME-Version: 1.0 Received: by 10.152.110.234 with SMTP id id10mr13067746lab.15.1351726930893; Wed, 31 Oct 2012 16:42:10 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.30.37 with HTTP; Wed, 31 Oct 2012 16:42:10 -0700 (PDT) In-Reply-To: References: <201210311807.q9VI7IcX000993@svn.freebsd.org> <1351707964.1120.97.camel@revolution.hippie.lan> <20121031193020.GJ3309@server.rulingia.com> <1351712425.1120.109.camel@revolution.hippie.lan> <50918AAD.2090906@freebsd.org> Date: Wed, 31 Oct 2012 23:42:10 +0000 X-Google-Sender-Auth: dzFv40A4jUeMN8nOBZD6IBE0oEc Message-ID: Subject: Re: svn commit: r242402 - in head/sys: kern vm From: Attilio Rao To: Jim Harris Content-Type: text/plain; charset=UTF-8 Cc: Ian Lepore , Adrian Chadd , src-committers@freebsd.org, Andre Oppermann , svn-src-all@freebsd.org, svn-src-head@freebsd.org, Peter Jeremy 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: Wed, 31 Oct 2012 23:42:14 -0000 On Wed, Oct 31, 2012 at 11:25 PM, Jim Harris wrote: > > > On Wed, Oct 31, 2012 at 3:55 PM, Attilio Rao wrote: >> >> On Wed, Oct 31, 2012 at 8:31 PM, Andre Oppermann >> wrote: >> > You can define CACHE_LINE_SIZE to 0 on those platforms. >> > Or to make it even more granular there could be a CACHE_LINE_SIZE_LOCKS >> > that is used for lock padding. >> >> I think that this is a bright idea, albeit under the condition that >> just like CACHE_LINE_SIZE it won't change during STABLE branches >> timeframe and that it must not be dependent by SMP option. >> >> What do you think about this patch?: >> http://www.freebsd.org/~attilio/cache_line_size_locks.patch > > > Should CACHE_LINE_SIZE_LOCKS still be defined as CACHE_LINE_SIZE on arm, > mips, etc. if SMP is enabled? This would ensure the padding that used to be > there in vpglock doesn't go away. As first thing, I'm strongly against having SMP-dependant lock sizes, as said so I won't be happy with whatever patch that changes lock sizes based on the SMP option presence or not. Said that, I'm not really sure if pad-aligned locks have the same performance weight on !Intel architectures. I suspect not. If this is not the case (then pad-aligned are important on some architectures where I used the 1 value) I just say to go and use CACHE_ALIGN_SIZE for them. I think the whole point of this patch was to prevent !Intel (or most of them, namely MIPS and ARM) architectures to avoid the pad-aligned effect at all, otherwise this patch looks moot to me. Said that, this changes completely the meaning of pad-align locks. If this patch goes in it switches from "mutexes padded and aligned to the cache line size" to "mutexes which can be padded and aligned if the architecture can have a real benefit from doing so". > I'm also wondering if this should be named something different, perhaps > LOCK_ALIGNMENT. I don't really mind whatever name you are happier with, so just pick up one. Attilio -- Peace can only be achieved by understanding - A. Einstein