Messages in this thread |  | | Subject | Re: kernel lock contention and scalability | Date | Thu, 08 Mar 2001 18:26:20 -0500 | From | Jeff Dike <> |
| |
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/
|  |