From owner-svn-src-user@FreeBSD.ORG Sat Oct 27 14:35:08 2012 Return-Path: Delivered-To: svn-src-user@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9DC0636; Sat, 27 Oct 2012 14:35:08 +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 4D4B38FC12; Sat, 27 Oct 2012 14:35:07 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so2841995lbd.13 for ; Sat, 27 Oct 2012 07:35:06 -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=F4ftH1bv+YOyZDoaGOfTQ7zpHERruZALBxYUpqXYkBs=; b=g4ThgqQ3BJ6g0M0HnEDu4OD7a06KvVGaE1nPrnEAxkCUsHwLW26H48n+8J3TJEZzON kCYOl9r7bR0qZUqCTCFDhwu9XLGXo58HiFr/z46Vks3y0gHt+8cuvwKLBx61KJCzLFSb zBfuUGgEXgP2RCsZ+Za0/7gTcSKVkVFjCRmkSvFrtFaH4IoqCYSoHr2BocJkVQToxalg FDV5Qk2G/PIq6wnsQxFr7r+Cb6QhwBBQrX7HDV5lETs5yz15aTx3tlot7idDtScplNi0 9lSJ9J9yhu0kjxYaHhb9vGOB5/vH+QCVCUmctXZk4yhtLtYi+xyGJjlsLwadDSTj+zpi rjgg== MIME-Version: 1.0 Received: by 10.152.104.50 with SMTP id gb18mr23433631lab.9.1351348505893; Sat, 27 Oct 2012 07:35:05 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.30.37 with HTTP; Sat, 27 Oct 2012 07:35:05 -0700 (PDT) In-Reply-To: <508A89EF.5070805@freebsd.org> References: <201210221418.q9MEINkr026751@svn.freebsd.org> <201210241136.06154.jhb@freebsd.org> <201210241414.30723.jhb@freebsd.org> <508965B3.2020705@freebsd.org> <5089A913.2040603@freebsd.org> <508A89EF.5070805@freebsd.org> Date: Sat, 27 Oct 2012 15:35:05 +0100 X-Google-Sender-Auth: 3HDSjAfCKHOsrN4UVWlQerQ8wH0 Message-ID: Subject: Re: svn commit: r241889 - in user/andre/tcp_workqueue/sys: arm/arm cddl/compat/opensolaris/kern cddl/contrib/opensolaris/uts/common/dtrace cddl/contrib/opensolaris/uts/common/fs/zfs ddb dev/acpica dev/... From: Attilio Rao To: Andre Oppermann Content-Type: text/plain; charset=UTF-8 Cc: mdf@freebsd.org, src-committers@freebsd.org, John Baldwin , svn-src-user@freebsd.org, Jeff Roberson , Bruce Evans X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 14:35:08 -0000 On 10/26/12, Andre Oppermann wrote: > On 26.10.2012 08:27, Attilio Rao wrote: >> On Thu, Oct 25, 2012 at 10:03 PM, Andre Oppermann >> wrote: >>> On 25.10.2012 18:21, Attilio Rao wrote: >>>> Did you see my (and also Jeff) objection to your proposal about this? >>>> You are deliberating ignoring this? >>> >>> >>> Well, I'm allowed to have a different opinion, am I? I'm not ignoring >>> your objection in the sense as I'm not trying to commit any of this to >>> HEAD while it is disputed. >>> >>> Mind you this whole conversation was started because I was trying to >>> solve >>> a problem with unfortunate cache line sharing for global mutexes in the >>> kernel .bss section on my *personal* svn branch. >> >> Andre, >> I'm sorry if you felt I was being harsh or confrontative. This was >> really not my intention and I apologize. > > I apologize too for being a bit difficult and taking some time understand > the differences in __aligned() regarding padding behavior. > >> Said that, I fail in seeing a proper technical discussion on your side >> on how what I propose is "overdoing it" or how do you plan to address >> the concerns people are raising with your proposal of bumping all lock >> sizes indiscriminately. > > I'm wary of micro-optimizing and generally prefer clean and for a > reader obvious approaches. That said my assumption on the distribution > of mutex use cases in the kernel was wrong. By counting from a grep > it seems that about half of the mutexes could possibly benefit from > being padded and the other half doesn't because it is in structures > and next to its data. Besides that, you are likely misunderstanding something about what I propose: what I'm proposing is completely transparent to developers. You will just need to declare a mtx like: struct mtx_unshare Giant; and then you can use the mtx(9) interface on it without any issue. I don't see how this is less clean than what you propose. It just enables the alignment/padding on a selection basis rather than indiscriminately. >> However, here is the first half of the patch I'd like to see in: >> http:///www.freebsd.org/~attilio/mtx_decoupled.patch > > >> This is just the part to give the ability to crunch different >> structures to the mtx KPI. Please note that from the users perspective >> the mtx KPI remains absolutely the same, so there is theoretically no >> KPI discontinuity, the support is absolutely transparent. > > This seems rather complicated. Instead of mtxlock2mtx() wouldn't > __containerof() work just as well? The __DEVOLATILE() looks a bit > dangerous. Are you sure the compiler won't reorder things it should > not? What do you mean with "rather complicated"? For the users of the primitive nothing changes at all. For the people that might read the code it is pretty much self-explanatory, in particular if you know how lock classes work in our locking scheme. Maybe I can add a comment or two to clarify. About the __DEVOLATILE your statement makes absolutely no sense. We are not accessing the cookie, we are just modifying the value of the pointer to go lower and then point to the struct mtx. This has nothing to do with cache effects of the lock cookie. Attilio -- Peace can only be achieved by understanding - A. Einstein