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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx> 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

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]