On Tue, 15 Jan 2002, Ed Tomlinson wrote:
> OK I3 also works fine with respect to my nice test. [...]
good!
> Watching with top 's 0.3' I can see them lose priority in the 3-10
> seconds it takes them to setup. This is not that critical if they are
> the only thing trying to run. If you have another (not niced) task
> eating cpu (like a kernel compile) then intactive startup time
> suffers. Startup time is wait time that _is_ noticed by users.
well, the kernel needs some 'proof' that a task is interactive, before it
gives it special attention.
the scheduler will give newly started up tasks some credit (if the parent
is interactive), but if they take too long to start up then there is
nothing it can do but to penalize them.
> Is there some way we could tell the scheduler or the scheduler could
> learn that a given _program_ is usually interactive so it should wait
> at bit (10 seconds on my box would work) before starting to increase
> its priority numbers?
there is a way: renicing. Either use nice +19 on the compilation job or
use nice -5 on the 'known good' tasks. Perhaps we should allow a nice
decrease of up to -5 from the default level - and things like KDE or Gnome
could renice interactive tasks, while things like compilation jobs would
run on the default priority.
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/
This archive was generated by hypermail 2b29 : Tue Jan 15 2002 - 21:00:54 EST