lkml.org 
[lkml]   [2001]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: kernel lock contention and scalability
Date
From
timw@splhi.com said:
> On a uniprocessor system, a simple fallback is to just use a semaphore
> instead of a spinlock, since you can guarantee that there's no point
> in scheduling the current task until the holder of the "lock" releases
> it.

Yeah, that works. But I'm not all that interested in compiling UML
differently for UP and SMP hosts.

> Otherwise, the spin calling sched_yield() each iteration isn't too
> horrible.

This looks a lot better. For UML, if there's a thread spinning on a lock,
there has to be a runnable thread holding it, and that thread will get a
timeslice before the spinning one (assuming that the thread holding the lock
hasn't called a blocking system call, which is something that I intend to make
sure can't happen).

> > That sounds like a pretty fundamental (and abusable) mechanism.
>
> It would be if it were generally available. The implementation on
> DYNIX/ptx requires a privilege (PRIV_SCHED IIRC), to be able to use
> it.

OK, that makes sense.

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:29    [W:0.039 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site