Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches

From: Rob Landley
Date: Wed Aug 13 2003 - 19:27:21 EST


On Saturday 09 August 2003 16:52, George Anzinger wrote:
> Ed Sweetman wrote:
> > the problem is you want a process that works like it was run on a single
> > tasking OS on an operating system that is built from the ground up to be
> > a multi-user multi-tasking OS

Considering the multi-tasking OS has 1000 times the CPU power, memory, and
disk space as the single-tasking OS did when it debuted, yet still loses to
it in some areas, isn't it at least worth looking at?

> > and you want both to work perfectly at peak performance

We're pondering various heuristics with which to to improve the situation and
you say we're persuing perfection. From heuristics.

Do you say these sort of things to the virtual memory people? (Since you
can't do it perfectly, why bother to swap at all? The perfect being the
enemy of the good, and all that.)

> > and you want it to know when you want which to work at
> > peak performance automatically.

I know for a fact that automatic determination of interactivity is possible.
In OS/2 you could speed up a compile by moving the mouse pointer over its
window repeatedly to give it extra clock ticks. (So far we've managed to
avoid anything quite so disgusting in Linux, but there exist OSes where it
was done. Having the keyboard and mouse and display be local devices is
actually the common case. It took X about ten years to finally start
optimizing for the common case on the output side with MIT shared memory
extensions and such...)

The scheduler actually has a lot of information to work with. Ingo's patches
strive to give it more information, and and Con's patches make much better
use of that information. This is a good thing.

> Well said :)

Actually, I didn't really consider that list of straw man arguments to be
worth commenting on the first time around. (I thought he was being
sarcastic...)

Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/