Date: Tue, 30 Oct 2012 01:38:45 +0000 From: Attilio Rao <attilio@freebsd.org> To: Jeff Roberson <jroberson@jroberson.net> Cc: mdf@freebsd.org, src-committers@freebsd.org, Andre Oppermann <andre@freebsd.org>, John Baldwin <jhb@freebsd.org>, svn-src-user@freebsd.org, Bruce Evans <brde@optusnet.com.au> 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/... Message-ID: <CAJ-FndDbi0bUoKsVcmDhKR25PsuB48bbekraSaeCT8oSzfsiQQ@mail.gmail.com> In-Reply-To: <CAJ-FndD40whTV=o1P8gMCaq9tKEtRg56xMKdjqnapVR6Awo7og@mail.gmail.com> References: <201210221418.q9MEINkr026751@svn.freebsd.org> <201210241136.06154.jhb@freebsd.org> <CAJ-FndAG-Qp%2B1aQvoL7YRj=R151Qe9_wNrUeOAaDsdYao_-zCQ@mail.gmail.com> <201210241414.30723.jhb@freebsd.org> <CAJ-FndAu6BGeMMbtFTLaSqy82mbhM9CVEyJ3Lb1WhAogJr59yA@mail.gmail.com> <CAJ-FndBqRpkBhCntd2aqwVYPu%2B2EHGeuXr5srLtrNNDK-ButxA@mail.gmail.com> <508965B3.2020705@freebsd.org> <CAJ-FndCMMH2Qy=rzzxagNVfgO9vF0xZY6B_vrnjmv_dXKNB5Dg@mail.gmail.com> <5089A913.2040603@freebsd.org> <CAJ-FndApwOo8xmZQyeqq0bGp8P13QWRqgmSDNg1_hbm7nrpOAQ@mail.gmail.com> <508A89EF.5070805@freebsd.org> <CAJ-FndC%2BujncG54_RMwKwdtvNCRJ2QojNuADWn59puwayCHs6A@mail.gmail.com> <CAJ-FndAhYk4R2AD3COmkOv3vYQganGXQKuO%2BkMQLaefTQSAejQ@mail.gmail.com> <CAJ-FndD40whTV=o1P8gMCaq9tKEtRg56xMKdjqnapVR6Awo7og@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Oct 28, 2012 at 5:42 PM, Attilio Rao <attilio@freebsd.org> wrote: > On Sat, Oct 27, 2012 at 5:27 PM, Attilio Rao <attilio@freebsd.org> wrote: >> On Sat, Oct 27, 2012 at 3:35 PM, Attilio Rao <attilio@freebsd.org> wrote: >>> On 10/26/12, Andre Oppermann <andre@freebsd.org> wrote: >>>> On 26.10.2012 08:27, Attilio Rao wrote: >>>>> On Thu, Oct 25, 2012 at 10:03 PM, Andre Oppermann <andre@freebsd.org> >>>>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndDbi0bUoKsVcmDhKR25PsuB48bbekraSaeCT8oSzfsiQQ>