From owner-svn-src-user@FreeBSD.ORG Wed Oct 31 08:17:40 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 0322BB49 for ; Wed, 31 Oct 2012 08:17:40 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3F2528FC15 for ; Wed, 31 Oct 2012 08:17:39 +0000 (UTC) Received: (qmail 65101 invoked from network); 31 Oct 2012 09:54:14 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 31 Oct 2012 09:54:14 -0000 Message-ID: <5090DE9E.5030301@freebsd.org> Date: Wed, 31 Oct 2012 09:17:34 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: attilio@FreeBSD.org 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/... References: <201210221418.q9MEINkr026751@svn.freebsd.org> <201210241414.30723.jhb@freebsd.org> <508965B3.2020705@freebsd.org> <5089A913.2040603@freebsd.org> <508A89EF.5070805@freebsd.org> <508F9C94.7080703@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 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: Wed, 31 Oct 2012 08:17:40 -0000 On 30.10.2012 23:59, Attilio Rao wrote: > On Tue, Oct 30, 2012 at 9:23 AM, Andre Oppermann wrote: >> On 30.10.2012 03:25, Attilio Rao wrote: >>> >>> On Tue, Oct 30, 2012 at 1:38 AM, Attilio Rao wrote: >>>> >>>> On Sun, Oct 28, 2012 at 5:42 PM, Attilio Rao wrote: >>> >>> >>> [ trimm ] >>> >>>>> >>>>> BTW, the mtx_sysuninit() introduction can be avoided by using this other >>>>> trick: >>>>> #define MTX_SYSINIT(name, mtx, desc, opts) >>>>> \ >>>>> static struct mtx_args name##_args = { >>>>> \ >>>>> (mtx), >>>>> \ >>>>> (desc), >>>>> \ >>>>> (opts) >>>>> \ >>>>> }; >>>>> \ >>>>> SYSINIT(name##_mtx_sysinit, SI_SUB_LOCK, SI_ORDER_MIDDLE, >>>>> \ >>>>> mtx_sysinit, &name##_args); >>>>> \ >>>>> SYSUNINIT(name##_mtx_sysuninit, SI_SUB_LOCK, SI_ORDER_MIDDLE, >>>>> \ >>>>> _mtx_destroy, __DEVOLATILE(void *, &(mtx)->mtx_lock)) >>>>> >>>>> I'm just not sure that I would like the use of __DEVOLATILE() even if >>>>> it would help in this case when introducing MTX_SYSINIT_UNSHARE() >>>>> because we will just need to reuse the same code. >>>>> >>>>> Also, the more I think about this the more I feel convinced that >>>>> mtxlock2mtx() should be static in kern_mutex.c. I can simply add a >>>>> note to _mutex.h as a reminder for it. >>>> >>>> >>>> Here is the patch that does both things and the one I would like to >>>> commit: >>>> http://www.freebsd.org/~attilio/mtx_decoupled3.patch >>> >>> >>> BTW, I've updated the patch in order to make use of __containerof() >>> rather than the manual frobbing. I had no idea that this method was >>> existing, many thanks to andre@ and mdf@ for signaling it. >>> Please refresh the patch. >> >> >> Thank you for the updated patch. I have no objections to the patch, >> though I'm not really qualified to have a final say on changes to the >> mutex code. > > Jeff has replied privately to me saying that he would have preferred > to see altogether also the implementation of padded mutexes along with > the mtx decoupling interface. > The following patch, does what expected: > http://www.freebsd.org/~attilio/mtx_decoupled_padalign.patch > > I converted a bunch of locks and they work fine even with > MTX_SYSINIT() with the small change contained in this patchset, so > that doesn't require a separate KPI in the end. > > The patch is being tested right now and I will commit as soon as I > will receive positive feedbacks. Haven't tested it but to me looks good and fulfills my requirements. :) -- Andre