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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
