From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH v3 3/5] MCS Lock: Barrier corrections Date: Thu, 7 Nov 2013 09:13:06 +0100 Message-ID: <20131107081306.GA32438@gmail.com> References: <1383773827.11046.355.camel@schen9-DESK> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org To: Linus Torvalds Cc: Tim Chen , Arnd Bergmann , "Figo. zhang" , Aswin Chandramouleeswaran , Rik van Riel , Waiman Long , Raghavendra K T , "Paul E.McKenney" , linux-arch@vger.kernel.org, Andi Kleen , Peter Zijlstra , George Spelvin , Michel Lespinasse , Ingo Molnar , Peter Hurley , "H. Peter Anvin" , Andrew Morton , linux-mm , Alex Shi , Andrea Arcangeli , Scott J Norton , linux-kernel@vger.kernel.org, Thomas Gleixner , Dave Hansen List-Id: linux-arch.vger.kernel.org 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 -- 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