Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760687AbZAHPbA (ORCPT ); Thu, 8 Jan 2009 10:31:00 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755859AbZAHPap (ORCPT ); Thu, 8 Jan 2009 10:30:45 -0500 Received: from bombadil.infradead.org ([18.85.46.34]:35362 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754457AbZAHPao (ORCPT ); Thu, 8 Jan 2009 10:30:44 -0500 Subject: Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning From: Peter Zijlstra To: Steven Rostedt Cc: Ingo Molnar , Linus Torvalds , "Paul E. McKenney" , Gregory Haskins , Matthew Wilcox , Andi Kleen , Chris Mason , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich In-Reply-To: References: <1231347442.11687.344.camel@twins> <1231365115.11687.361.camel@twins> <1231366716.11687.377.camel@twins> <1231408718.11687.400.camel@twins> <20090108141808.GC11629@elte.hu> <1231426014.11687.456.camel@twins> <1231428220.11687.464.camel@twins> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 08 Jan 2009 16:30:05 +0100 Message-Id: <1231428605.11687.466.camel@twins> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1044 Lines: 27 On Thu, 2009-01-08 at 10:28 -0500, Steven Rostedt wrote: > On Thu, 8 Jan 2009, Peter Zijlstra wrote: > > in the unlikely case we schedule(), that seems expensive enough to want > > to make the spin case ever so slightly faster. > > OK, that makes sense, but I would comment that. Otherwise, it just looks > like another misuse of the unlikely annotation. OK, sensible enough. > > > Should we need to do a "get_cpu" or something? Couldn't the CPU disappear > > > between these two calls. Or does it do a stop-machine and the preempt > > > disable will protect us? > > > > Did you miss the preempt_disable() a bit up? > > No, let me rephrase it better. Does the preempt_disable protect against > another CPU from going off line? Does taking a CPU off line do a > stop_machine? Yes and yes. -- 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/