[lkml]   [2009]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH][RFC]: mutex: adaptive spin
On Tue, Jan 06, 2009 at 03:00:47PM -0800, Linus Torvalds wrote:
> Well, if you didn't go to sleep, a few more questions..

I know this one! Me sir, me me me!

> > int __sched
> > mutex_lock_killable_nested(struct mutex *lock, unsigned int subclass)
> > {
> > + int ret;
> > +
> > might_sleep();
> > - return __mutex_lock_common(lock, TASK_KILLABLE, subclass, _RET_IP_);
> > + ret = __mutex_lock_common(lock, TASK_KILLABLE, subclass, _RET_IP_);
> > + if (!ret)
> > + lock->owner = current;
> > +
> > + return ret;
> 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().

That would make the whole exercise rather pointless; the only time worth
spinning really is if you're the only other one waiting for it ... if
there's already a waiter, you might as well go to sleep.

Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."

 \ /
  Last update: 2009-01-07 00:13    [W:0.247 / U:13.248 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site