From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by kanga.kvack.org (Postfix) with ESMTP id C3FC06B0146 for ; Thu, 7 Nov 2013 03:22:27 -0500 (EST) Received: by mail-pd0-f175.google.com with SMTP id g10so257687pdj.34 for ; Thu, 07 Nov 2013 00:22:27 -0800 (PST) Received: from psmtp.com ([74.125.245.134]) by mx.google.com with SMTP id hi3si1829746pbb.3.2013.11.07.00.22.25 for ; Thu, 07 Nov 2013 00:22:26 -0800 (PST) Received: by mail-vc0-f169.google.com with SMTP id hu8so134312vcb.28 for ; Thu, 07 Nov 2013 00:22:24 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20131107081306.GA32438@gmail.com> References: <1383773827.11046.355.camel@schen9-DESK> <20131107081306.GA32438@gmail.com> Date: Thu, 7 Nov 2013 17:22:24 +0900 Message-ID: Subject: Re: [PATCH v3 3/5] MCS Lock: Barrier corrections From: Linus Torvalds Content-Type: multipart/alternative; boundary=047d7b67747221cbd004ea91f737 Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar Cc: Waiman Long , Arnd Bergmann , Rik van Riel , Aswin Chandramouleeswaran , "Paul E.McKenney" , Raghavendra K T , "Figo. zhang" , linux-arch@vger.kernel.org, Andi Kleen , Peter Zijlstra , George Spelvin , Tim Chen , Michel Lespinasse , Ingo Molnar , Peter Hurley , "H. Peter Anvin" , Andrew Morton , linux-mm , Andrea Arcangeli , Alex Shi , linux-kernel@vger.kernel.org, Scott J Norton , Thomas Gleixner , Dave Hansen , Matthew R Wilcox , Will Deacon , Davidlohr Bueso --047d7b67747221cbd004ea91f737 Content-Type: text/plain; charset=UTF-8 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" 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 > --047d7b67747221cbd004ea91f737 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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 d= o *not* want to factor out some half-arsed implementation and then have lat= er patches to fix up the crud. Nor when multiple different locks then use t= hat common code.

So I think it needs to be *clearly* great code before it get= s factored out. Because before it is great code, it should not be shared wi= th anything else.

=C2=A0=C2=A0=C2=A0=C2=A0 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:

=C2=A0 [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<= br> 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,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ingo
--047d7b67747221cbd004ea91f737-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org