>And you seem to have a misconception about sched_yield, too. If a
>machine has n tasks, half of which are doing CPU-intense work and the
>other half of which are just yielding... why on Earth would the yielding
>tasks get any noticeable amount of CPU use?
Because they are not blocking. They are in an endless CPU burning loop. They
should get CPU use for the same reason they should get CPU use if they're the
only threads running. They are always ready-to-run.
>Quite frankly, even if the supposed standard says nothing of this... I
>do not care: calling sched_yield in a loop should not show up as a CPU
>hog.
It has to. What if the only task running is:
while(1) sched_yield();
What would you expect? You cannot use sched_yield as a replacement for
blocking or scheduling priority. You cannot use it to be 'nice'. You can only
use it to try to give other threads a chance to run, usually to give them a
chance to release a resource.
Imagine if a spinlock uses sched_yield in its wait loop, what would you
expect on a dual-CPU system with a process on CPU A holding the lock? You
*want* the sched_yield process to burn the CPU fully, so that it notices the
spinlock acquisition as soon as possible.
While linux's sched_yield behavior is definitely sub-optimal, the particular
criticism being leveled (that sched_yield processes get too much CPU) is
wrong-headed.
DS
-
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/
This archive was generated by hypermail 2b29 : Sun Jun 23 2002 - 22:00:16 EST