lkml.org 
[lkml]   [2003]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Interactivity improvements
I have a few ideas about the interactivity problem that I thought i 
would share.

First, the whole problem with interactive tasks turning into CPU hogs,
and vice-versa. The current implementation is fairly good at estimating
the interactivity of a new process isn't it? I assume it keeps some sort
of statitistice on what a process has been doing in the past, so if a
process starts to deviate from it's previous behavior quite a bit (say
an interactive task starts finishing time slices, or a CPU hog starts
sleeping a lot) couldn't we reset the priority, etc and let the
interactivity estimator re-estimate the interactivity as if it was a new
task. That way no task would get a real chance to starve others, while
keeping interactive tasks interactive (interactive tasks that become CPU
hogs for short peroids of time would have a pretty good chance to
smarten up before they really get penalized).

Another point is compilers, they tend to do a lot of disk I/O then
become major CPU hogs, could we have some sort or heuristic that reduces
the bonuses for sleeping on block I/O rather than other kinds of I/O
(say pipes and network I/O in the case of X). This would prevent tasks
like compilers from getting real bonuses for reading alot of files at
startup.

Finally, the interactivity estimator seems to be quite a bit of code,
which certain people have no real useful (in servers for example) and I
would imagine that it does reduce throughput, which is not a big deal in
desktops, but in a server environment it's not good, so maybe a
CONFIG_INTERACTIVE_ESTIMATOR or something similar would be an idea to
keep the server people happy, just have an option to completely get rid
of the extra overhead of having a really nice interactivity estimator. I
could be an idiot though, and I imagine that I will be needing some
asbestos for saying this, but I thought I would voice my opinion.

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.117 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site