Re: [PATCH v3 3/5] MCS Lock: Barrier corrections

[Linus Torvalds <torvalds@linux-foundation.org>]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

I don't necessarily mind the factoring out, I just think it needs to be
really solid and clear if - and *before* - we do this. We do *not* want to
factor out some half-arsed implementation and then have later patches to
fix up the crud. Nor when multiple different locks then use that common
code.

So I think it needs to be *clearly* great code before it gets factored out.
Because before it is great code, it should not be shared with anything else.

     Linus
On Nov 7, 2013 5:13 PM, "Ingo Molnar" <mingo@kernel.org> wrote:

>
> Linus,
>
> A more general maintenance question: do you agree with the whole idea to
> factor out the MCS logic from mutex.c to make it reusable?
>
> This optimization patch makes me think it's a useful thing to do:
>
>   [PATCH v3 2/5] MCS Lock: optimizations and extra comments
>
> as that kicks back optimizations to the mutex code as well. It also
> brought some spotlight on mutex code that it would not have gotten
> otherwise.
>
> That advantage is also its disadvantage: additional coupling between rwsem
> and mutex logic internals. But not like it's overly hard to undo this
> change, so I'm in general in favor of this direction ...
>
> So unless you object to this direction, I planned to apply this
> preparatory series to the locking tree once we are all happy with all the
> fine details.
>
> Thanks,
>
>         Ingo
>

[-- Attachment #2: Type: text/html, Size: 1753 bytes --]