> processes tend to max out at one extreme or the other
>
> processes that get stalled by a huge overall load of the machine
> are forced to sleep, too; yet they are not interactive.
Not running != Sleeping
> priority should be based on things the processes did, not on what
> they haven't done.
It _is_ based on something the process has done: sleeping in the kernel
> but for interactive tasks, latency is all-important
> if the task can't provide a result in a short timeslice it already
> failed to provide low latency and should not be considered interactive
> any more.
Ahh, but you are confusing timeslice with the time a process runs for.
This is what I pointed out in my initial email was your flaw :)
A process may have a 100ms timeslice, but only run for 1ms at a time
(100x before recalculating its quanta). This is the intention of giving
large timeslices to interactive tasks: not that they need all 100ms at
_once_ but they may need some of it soon, and when they need it they
really NEED it, so make sure they have enough timeslice such that there
is plenty available when they wake up (since the latency is important,
as you said).
> but the time slice should not be large enough to stall other
> processes, which is extremely important for interactivity
Once a process stalls other processes (i.e. by running a long time i.e.
by being a CPU hog) then it loses its interactive bonus.
The heuristic works. No one doubts that, modulo the corner cases we are
working on fixing. I suggest you read the code.
Robert Love
-
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/