Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752210AbZAFQl7 (ORCPT ); Tue, 6 Jan 2009 11:41:59 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751255AbZAFQlr (ORCPT ); Tue, 6 Jan 2009 11:41:47 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:38729 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751119AbZAFQlq (ORCPT ); Tue, 6 Jan 2009 11:41:46 -0500 Date: Tue, 6 Jan 2009 08:40:40 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Ingo Molnar cc: Peter Zijlstra , Matthew Wilcox , Andi Kleen , Chris Mason , Andrew Morton , linux-kernel@vger.kernel.org, linux-fsdevel , linux-btrfs , Thomas Gleixner , Steven Rostedt , Gregory Haskins , Nick Piggin Subject: Re: [PATCH][RFC]: mutex: adaptive spin In-Reply-To: Message-ID: References: <1230722935.4680.5.camel@think.oraclecorp.com> <20081231104533.abfb1cf9.akpm@linux-foundation.org> <1230765549.7538.8.camel@think.oraclecorp.com> <87r63ljzox.fsf@basil.nowhere.org> <20090103191706.GA2002@parisc-linux.org> <1231093310.27690.5.camel@twins> <20090104184103.GE2002@parisc-linux.org> <1231242031.11687.97.camel@twins> <20090106121052.GA27232@elte.hu> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1523 Lines: 38 On Tue, 6 Jan 2009, Linus Torvalds wrote: > > So it should be renamed. Something like "task_is_oncpu()" or whatever. Another complaint, which is tangentially related in that it actually concerns "current". Right now, if some process deadlocks on a mutex, we get hung process, but with a nice backtrace and hopefully other things (that don't need that lock) still continue to work. But if I read it correctly, the adaptive spin code will instead just hang. Exactly because "task_is_current()" will also trigger for that case, and now you get an infinite loop, with the process spinning until it looses its own CPU, which obviously will never happen. Yes, this is the behavior we get with spinlocks too, and yes, lock debugging will talk about it, but it's a regression. We've historically had a _lot_ more bad deadlocks on mutexes than we have had on spinlocks, exactly because mutexes can be held over much more complex code. So regressing on it and making it less debuggable is bad. IOW, if we do this, then I think we need a BUG_ON(task == owner); in the waiting slow-path. I realize the test already exists for the DEBUG case, but I think we just want it even for production kernels. Especially since we'd only ever need it in the slow-path. 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/