In the general case, the kernel cannot determine which N threads of a
set of M threads (where M > N) are the best to run at a given point in time.
"best" here doesn't refer to goodness(), but to user-level application
performance. The pipeline David referred to may well be implemented
entirely at user-level, using UL spin-locks that are invisible to the
kernel. There is therefore no way for the kernel to ensure correct
scheduling. All it knows is that a thread called sched_yield(), but
has no idea why, or under what circumstances it might want to run
again.
All of this stuff is the standard UL vs. Kernel thread argument. Linux
doesn't solve it, rightfully so at the moment, but to pretend that the
current implementation is even close to "correct" for multithreaded
applications is a joke. Fortunately, it just so happens to work for
most of the time :)
--p
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/