Thread (284 messages) 284 messages, 35 authors, 2009-01-12

Re: [PATCH][RFC]: mutex: adaptive spin

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2009-01-07 00:06:07
Also in: linux-fsdevel, lkml


On Tue, 6 Jan 2009, Matthew Wilcox wrote:
quoted
This looks ugly. Why doesn't __mutex_lock_common() just set the lock 
owner? Hate seeing it done in the caller that has to re-compute common 
(yeah, yeah, it's cheap) and just looks ugly.
Because __mutex_lock_common() is the slow path.  The fast path is a
couple of assembly instructions in asm/mutex.h.  If the lock isn't
contended, it will never call __mutex_lock_common().
No, that's not it.

Look at the callers. They are _all_ the slow path. They looked like this:

	might_sleep();
	return __mutex_lock_common(lock, TASK_KILLABLE, subclass, _RET_IP_);

Yes, you _also_ need to set the owner in the fast-path, but that's all 
entirely different. This is the debug case, which _always_ calls the 
slow-path.

So what I'm saying is that the slow-path should just set it. And then yes, 
we _also_ need to set it in the fast-path, but at least we don't need to 
set it in all the debug versions that just call the slow path!

			Linus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help