Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752800AbaFFRW0 (ORCPT ); Fri, 6 Jun 2014 13:22:26 -0400 Received: from mail-vc0-f172.google.com ([209.85.220.172]:63645 "EHLO mail-vc0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752160AbaFFRWW (ORCPT ); Fri, 6 Jun 2014 13:22:22 -0400 MIME-Version: 1.0 In-Reply-To: <20140606171145.GU13930@laptop.programming.kicks-ass.net> References: <1402070140-15090-1-git-send-email-davidlohr@hp.com> <1402070140-15090-3-git-send-email-davidlohr@hp.com> <1402070987.2207.75.camel@dabdike.int.hansenpartnership.com> <20140606171145.GU13930@laptop.programming.kicks-ass.net> Date: Fri, 6 Jun 2014 10:22:21 -0700 X-Google-Sender-Auth: VNQwkmhnZYzHLKvfy9Iwnqmwcq4 Message-ID: Subject: Re: [PATCH 2/2] locking/rwsem: Disable optimistic spinning for PA-RISC From: Linus Torvalds To: Peter Zijlstra Cc: James Bottomley , Davidlohr Bueso , Ingo Molnar , Mikulas Patocka , Jason Low , Waiman Long , "James E.J. Bottomley" , Paul McKenney , John David Anglin , "Chandramouleeswaran, Aswin" , Linux Kernel Mailing List , Parisc List , David Miller , James Hogan , Chris Metcalf , Vineet Gupta Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 6, 2014 at 10:11 AM, Peter Zijlstra wrote: > > +config ARCH_NO_ATOMIC_RMW > + def_bool y > + depends on PARISC || SPARC32 || METAG_ATOMICITY_LOCK1 || (TILE && !TILEGX) || (ARC && !ARC_HAS_LLSC) Ugh. We've had these kinds of things before, and they are broken and nasty to maintain. Just make it config ARCH_SUPPORTS_ATOMIC_RMW bool which defaults to no. And then make MUTEX_SPIN_ON_OWNER depend on that. And then we can add "select ARCH_SUPPORTS_ATOMIC_RMW" to the few architectures we (a) care about and (b) know work. So start with x86, arm, powerpc and sparc64, and then the rest can just add their own oneliners if they care. Remember, most people really won't ever care about this, simply because it only matters if you have enough CPU's for the whole spinning thing to make a noticeable difference. So missing some odd architecture _really_ doesn't matter. And we really really *really* shouldn't have these kinds of "random really odd architecture details" in the generic code, not even if it's something as specific as kernel/Kconfig.locks. Linus Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/