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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
