On Sun, 2006-11-19 at 12:44 -0500, Lee Revell wrote:
> On Sun, 2006-11-19 at 08:51 +0100, Mike Galbraith wrote:
> > That makes sense, I/O tasks don't generally hold the cpu for extended
> > periods, whereas a cpu bound task does.
>
> So what can we do about I/O intensive tasks that also want a lot of CPU,
> for example, the bloatier Gnome/KDE apps? Evolution is the worst for
> me.
Evolution has big trouble with the ext3 (and maybe others) journal.
I've _never_ seen evolution having scheduler priority problems, only
journal problems (absolutely every damn time hefty I/O is going on).
What should we do about I/O tasks that decide to use massive cpu?
IMHO, absolutely nothing beyond what ever we decide to do with any other
cpu intensvive task. There is nothing special about scheduling I/O
heavy tasks. If it uses massive cpu for sustained periods, it must pay
the price. In the meantime, an I/O intensive task that decides to use
heavy cpu will round-robin at relatively high frequency with every other
"interactive" task, which may also be doing a burst of cpu heavy work.
The reason for doing that cpu intensive burst just doesn't matter.
Currently, we special case I/O tasks to limit the dynamic priority boost
they can get via I/O. I think that is wrong.
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
