Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752833AbZAFP5W (ORCPT ); Tue, 6 Jan 2009 10:57:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751072AbZAFP5J (ORCPT ); Tue, 6 Jan 2009 10:57:09 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:60224 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750888AbZAFP5H (ORCPT ); Tue, 6 Jan 2009 10:57:07 -0500 Date: Tue, 6 Jan 2009 07:55:58 -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: <20090106121052.GA27232@elte.hu> 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: 1198 Lines: 30 On Tue, 6 Jan 2009, Ingo Molnar wrote: > > The thing i like most about Peter's patch (compared to most other adaptive > spinning approaches i've seen, which all sucked as they included various > ugly heuristics complicating the whole thing) is that it solves the "how > long should we spin" question elegantly: we spin until the owner runs on a > CPU. The other way around, you mean: we spin until the owner is no longer holding a cpu. I agree that it's better than the normal "spin for some random time" model, but I can't say I like the "return 0" cases where it just retries the whole loop if the semaphore was gotten by somebody else instead. Sounds like an easyish live-lock to me. I also still strongly suspect that whatever lock actually needs this, should be seriously re-thought. But apart from the "return 0" craziness I at least dont' _hate_ this patch. Do we have numbers? Do we know which locks this matters on? 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/