Messages in this thread | | | Date | Wed, 19 Jun 2002 14:04:25 +0200 (CEST) | From | Ingo Molnar <> | Subject | RE: Question about sched_yield() |
| |
On Wed, 19 Jun 2002, Bill Davidsen wrote:
> Consider the case where a threaded application and a CPU hog are > running. In sum the threaded process is also a hog, although any one > thread is not.
it is a mistake to assume that sched_yield() == 'threaded applications'.
sched_yield() is a horrible interface to base userspace spinlocks on, it's not in any way cheaper than real blocking, even in the best-case situation when there is no 'useless' yielding back and forth. In the worst-case situation it can be a few orders more expensive (!) than blocking-based solutions. LinuxThread's use of sched_yield() was and remains a hack. I'm actually surprised that it works for real applications.
We are trying to improve things as much as possible on the kernel scheduler side, but since there is absolutely no object/contention information available for kernel space (why it wants to schedule away, which other processes are using the blocked object, etc.), it's impossible to do a perfect job - in fact it's not even possible to do a 'good' job.
IMO people interested in high-performance threading should concentrate on the lightweight, kernel-backed userspace semaphores patch(es) that have been presented a few weeks ago, and merge those concepts into LinuxThreads (or into their own threading/spinlock solutions). Those patches do it properly, and the scheduler will be able to give all the help it can.
Ingo
- 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/
| |