Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches
From: George Anzinger (george_at_mvista.com)
Date: 08/14/03
- Previous message: Christoph Hellwig: "Re: [PATCH] call drv->shutdown at rmmod"
- In reply to: Rob Landley: "Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches"
- Next in thread: Rob Landley: "Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches"
- Reply: Rob Landley: "Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 14 Aug 2003 01:01:11 -0700 To: rob@landley.net
Rob Landley wrote:
> 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...)
Well, I think he was too, but I am trying to say (as I think you are
too) that it is not far from being a realistic goal.
As to timing, I just changed ISPs and was off line for a few days...
>
-- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml - 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/
- Previous message: Christoph Hellwig: "Re: [PATCH] call drv->shutdown at rmmod"
- In reply to: Rob Landley: "Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches"
- Next in thread: Rob Landley: "Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches"
- Reply: Rob Landley: "Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
