From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning Date: Fri, 9 Jan 2009 10:24:16 -0800 (PST) Message-ID: References: <1231441350.14304.48.camel@think.oraclecorp.com> <1231498062.11687.608.camel@twins> <1231513614.442.11.camel@twins> <1231524964.442.103.camel@twins> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Steven Rostedt , Chris Mason , Ingo Molnar , paulmck@linux.vnet.ibm.com, Gregory Haskins , Matthew Wilcox , Andi Kleen , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich To: Peter Zijlstra Return-path: In-Reply-To: <1231524964.442.103.camel@twins> List-ID: On Fri, 9 Jan 2009, Peter Zijlstra wrote: > > On that note: > > Index: linux-2.6/kernel/mutex.c > =================================================================== > --- linux-2.6.orig/kernel/mutex.c > +++ linux-2.6/kernel/mutex.c > @@ -220,7 +220,9 @@ __mutex_lock_common(struct mutex *lock, > __set_task_state(task, state); > > /* didnt get the lock, go to sleep: */ > + preempt_disable(); > spin_unlock_mutex(&lock->wait_lock, flags); > + preempt_enable_no_resched(); > schedule(); Yes. I think this is a generic issue independently of the whole adaptive thing. In fact, I think wee could make the mutex code use explicit preemption and then the __raw spinlocks to make this more obvious. Because now there's a hidden "preempt_enable()" in that spin_unlock_mutex, and anybody looking at the code and not realizing it is going to just say "Whaa? Who is this crazy Peter Zijlstra guy, and what drugs is he on? I want me some!". Because your patch really doesn't make much sense unless you know how spinlocks work, and if you _do_ know how spinlocks work, you go "eww, that's doing extra preemption crud in order to just disable the _automatic_ preemption crud". Linus