From owner-svn-src-user@FreeBSD.ORG Tue Oct 30 01:38:48 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 D3520CD9; Tue, 30 Oct 2012 01:38:48 +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 54A378FC08; Tue, 30 Oct 2012 01:38:46 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so4485506lbd.13 for ; Mon, 29 Oct 2012 18:38:46 -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=lb71FKAQ0YRu3Md2e22Bc+fFVgvLlh0eV7qWrPNRi1g=; b=N35spmQCqLvZEVyc8dAwEWPBUc6dYSn3zovMzbiQqp1eauG5rvUgvJXDSBOl5XbYEX xWu6c7H14TcGkzeZJ86GrSrFnhn9maBGBRouWZ9v5n74vZxnhDJy2HFJ6HFqDrjdqEXN jRM8CiWZ6w+y6ueKXxceaXL387LsVlURqRIxBSdPK1Mw485XX8uc5fHOUW8uwhtCX/2t 5CkNlZFdWy8HRkd8+ALIb0DPTpCH5pK7O3CT+sgEHkTtMnX8Ip6YjqYqDP5I9WqTZS1V SskjWbhSkIb0rOr+SxH57OTyUCcdNB0fz8kiJ2aI1soojU+3wZnXBrhfozjwZRjmyqsn YiVg== MIME-Version: 1.0 Received: by 10.152.104.50 with SMTP id gb18mr29532042lab.9.1351561125908; Mon, 29 Oct 2012 18:38:45 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.30.37 with HTTP; Mon, 29 Oct 2012 18:38:45 -0700 (PDT) In-Reply-To: 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: Tue, 30 Oct 2012 01:38:45 +0000 X-Google-Sender-Auth: 2mZMDEJ9ZHgxrwYfTAoSb146XBU 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: Jeff Roberson Content-Type: text/plain; charset=UTF-8 Cc: mdf@freebsd.org, src-committers@freebsd.org, Andre Oppermann , John Baldwin , svn-src-user@freebsd.org, 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: Tue, 30 Oct 2012 01:38:49 -0000 On Sun, Oct 28, 2012 at 5:42 PM, Attilio Rao wrote: > On Sat, Oct 27, 2012 at 5:27 PM, Attilio Rao wrote: >> On Sat, Oct 27, 2012 at 3:35 PM, Attilio Rao wrote: >>> 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. >> >> Here we go with further comments tweaks. >> Also, in order to make it a complete NOP from KPI perspective I had to >> change the way the mtx_assert() wrapper was implemented as in v1 it >> wasn't correctly handling the const qualifier. >> I think the result is better now and you should refer to this patch for reviews: >> http://www.freebsd.org/~attilio/mtx_decoupled2.patch > > 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 Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein