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/...

[Attilio Rao]

On Sun, Oct 28, 2012 at 5:42 PM, Attilio Rao <attilio at freebsd.org> wrote:
> On Sat, Oct 27, 2012 at 5:27 PM, Attilio Rao <attilio at freebsd.org> wrote:
>> On Sat, Oct 27, 2012 at 3:35 PM, Attilio Rao <attilio at freebsd.org> wrote:
>>> On 10/26/12, Andre Oppermann <andre at freebsd.org> wrote:
>>>> On 26.10.2012 08:27, Attilio Rao wrote:
>>>>> On Thu, Oct 25, 2012 at 10:03 PM, Andre Oppermann <andre at 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