>Exactly. The reason the behavior is odd is not because the sched_yield
>task is getting any CPU, David. I realize sched_yield is not equivalent
>to blocking.
Good.
>The reason this behavior is suspect is because the task is receiving a
>similar amount of CPU to tasks that are _not_ yielding but in fact doing
>useful work for the entire duration of their timeslice.
This is the same error repeated again. Since you realize that an endless
loop on sched_yield is *not* equivalent to blocking, why do you then say "in
fact doing useful work"? By what form of ESP is the kernel supposed to
determine that the sched_yield task is not 'doing useful work' and the other
task is?
The kernel doesn't know the loop is endless. For all it knows, as soon as
another process gets a drop of CPU, the yielding process may be able to
succeed. And because the yielding process is being nice (by yielding), it
should get better and better treatment over processes that are burning CPU
rather than yielding.
>A task that continually uses its timeslice vs one that yields should
>easily receive a greater amount of CPU, but this is not the case.
Why should the mean task get preferential treatment over the nice task when
both are always ready-to-run?
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