Re: kernel lock contention and scalability

[Jeff Dike <jdike@karaya.com>]

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