From owner-svn-src-all@FreeBSD.ORG Wed Oct 31 18:33:53 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 B6CCE72E; Wed, 31 Oct 2012 18:33:53 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id BDAB58FC0C; Wed, 31 Oct 2012 18:33:52 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so1645116lbd.13 for ; Wed, 31 Oct 2012 11:33:51 -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=Fba1C/EP7k1s5uJF+KTU7e7As8c89jj4h0MISZtfNfs=; b=bZlG/+pC4mQH1ZiaBfu1vOf6NH210AkhAT2P+QEUbD6wa5aGassXFJpuRYnLPizh0j 8lG3JP7XEJHU4h3FHVM1HNP/nvgctAtHYdCAzMhqVlNxzA9S+AQON9SAL/SOApa110rN KN23VVDY7U+TKIwjStuOExo4bPpi8G01g+fehzT/JLNWFLujxYAgiediSWm4TZBu7GAr 66f1UZG4gIHFvTJQhc4hXKo7Jqpu+JAjgRn9j1ACMJJPs9nUjhdriU/2j+EGMyledaUf qipkLboOEa1Lbm/kXwQOVKVT3hWxPyjnZzTJC6bpACxACnu+NDzqDbpGjvDalamWMNHh 7K3A== MIME-Version: 1.0 Received: by 10.152.110.234 with SMTP id id10mr12416850lab.15.1351708431305; Wed, 31 Oct 2012 11:33:51 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.30.37 with HTTP; Wed, 31 Oct 2012 11:33:51 -0700 (PDT) In-Reply-To: <1351707964.1120.97.camel@revolution.hippie.lan> References: <201210311807.q9VI7IcX000993@svn.freebsd.org> <1351707964.1120.97.camel@revolution.hippie.lan> Date: Wed, 31 Oct 2012 18:33:51 +0000 X-Google-Sender-Auth: 08QWXV9Zg0uRD5XXoyabfGwHDNY Message-ID: Subject: Re: svn commit: r242402 - in head/sys: kern vm From: Attilio Rao To: Ian Lepore 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: Wed, 31 Oct 2012 18:33:53 -0000 On Wed, Oct 31, 2012 at 6:26 PM, Ian Lepore wrote: > On Wed, 2012-10-31 at 18:10 +0000, 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. >> >> Thanks, >> Attilio >> >> > > Doesn't this padding to cache line size only help x86 processors in an > SMP kernel? I was expecting to see some #ifdef SMP so that we don't pay > a big price for no gain in small-memory ARM systems and such. But maybe > I'm misunderstanding the reason for the padding. I didn't want to do this because this would be meaning that SMP option may become a completely killer for modules/kernel ABI compatibility. Also, if you look at the modified list of locks I don't think they should be too much, I hardly believe ARM UP is going to hurt that much from loosing some padding in tdq structures or callout. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein