From owner-svn-src-user@FreeBSD.ORG Sun Oct 28 17:42:37 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 77540932; Sun, 28 Oct 2012 17:42:37 +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 2805C8FC08; Sun, 28 Oct 2012 17:42:35 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so4207915lag.13 for ; Sun, 28 Oct 2012 10:42:34 -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=cxkd49lSYW1yJr0swNCwp1Ha3QPK63DTiDPQ4R/BUFk=; b=qg1aLxi97/cl93/ZHHS1BhG5LGs8RkjEPJLW1gLI/u6mTFkrwhvz0CtrIV3iIW/Kr+ /D6FQPJ0MAFl27vQlGirBMVKflztjo89BAX8yik8Dml8xO9lL0rRw6H8GcpmvYpb+7Ww CmAylC8lwO7pV3SCrj5SL+aqg0bhgyqdwN2fji9lADhQDfyfCVUXIJw7pM7/IZWQz/yD 7hKYG6buhMyX244wP1UyemeaaTqWU6XDKAUtaQ1v2nVw4xGdCmC7TN+YCefynhn8/rFt u64I9NSNF517KnEBZJ6/kk99gJ+cUazmTqGMqir7L1zIKIvsVK6UYfI1Xw7B31YuJ/tB ZW5g== MIME-Version: 1.0 Received: by 10.152.104.50 with SMTP id gb18mr25643796lab.9.1351446154788; Sun, 28 Oct 2012 10:42:34 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.30.37 with HTTP; Sun, 28 Oct 2012 10:42:34 -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: Sun, 28 Oct 2012 17:42:34 +0000 X-Google-Sender-Auth: ptQKedc0N0pxyNX7ucio9CSgmu0 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: Sun, 28 Oct 2012 17:42:37 -0000 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. Attilio -- Peace can only be achieved by understanding - A. Einstein