> I can think of some circumstances where one would want the *opposite*
> of this patch. Consider a "time-sharing" system running both
> CPU-intensive "batch" tasks and "interactive" tasks. There is going to
> be a tradeoff between efficiency / throughput of the batch tasks and
> the response times of interactive ones. [...]
this mechanizm is already part of the scheduler and is not affected by my
patch. Interactive tasks get their '->counter' value increased gradually
via the recalculate code in the scheduler, which after some time gives
them effective priority above that of CPU-intensive processes.
To see this mechanizm working, just boot into the stock kernel or try a
kernel with the patch applied, start a few CPU-intensive processes, eg.
a couple of subshells doing an infinite loop:
while N=1; do N=1; done &
while N=1; do N=1; done &
while N=1; do N=1; done &
while N=1; do N=1; done &
and see how the interactive shell is still responding instantaneously in
such a mixed workload, despite having the same static priority as the
subshells.
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/