Re: Scheduler: Process priority fed back to parent?

[Timothy Miller <miller@techsource.com>]

Muli Ben-Yehuda wrote:
> On Tue, Mar 16, 2004 at 11:19:46AM -0500, Timothy Miller wrote:
> 
> 
>>Unfortunately, the OS has to play babysitter to processes, because 
>>they're guaranteed to misbehave.  Preemption exists to ensure fairness 
>>amongst processes.  Thus, while you're right that it would be nice to 
>>have processes report their CPU requirements, if we were to actually DO 
>>that, it would be a disaster.
> 
> 
> I agree we should do the best thing possible without any prior
> knowledge of what a process should do. I don't agree we should add
> pointless complexity to the scheduler for dubious gains (getting rid
> of the very short ramp up time). Of course, if you think it's useful,
> feel free to implement it and let's resume the discussion when we have
> some numbers. 


If shortening ramp-up times is the only benefit, then it's not worth the 
effort.  The objective is continuity and over-all feel of the system.

With Nick's and Con's schedulers, if you have a set of processes that 
are running continuously, then after a brief period, everything has 
settled into its ideal state.  The interactive processes are 
interactive, the CPU-bound ones are penalized, etc.

But real systems aren't like this.  Processes are launched and killed 
constantly.  Consider what a shell script does!  To have program 
behavior from one time affect how the program is run at a later time 
would allow system behavior to be smooth over many launch/kill cycles.


And having parent processes (eg. shell) maintain information on child 
behavior would also help, because then a shell script would behave more 
like a single program than many independent programs.  Compiles would 
affect the system less because 'make' would maintain information on 
compiler behavior, making the impact of compiler launches much less 
negative.

In FACT, that I think I may be on to something here... Hmmm.  So far, 
process schedulers have been trying to BOOST priority of interactive 
processes.  That's great.  But maybe an even BIGGER problem is that 
every time gcc (and cc1) is launched during a kernel compile, it's given 
too high of a priority, and by the time the priority is corrected, the 
compile has finished for that .c file.

This sounds SO familiar... I know this has been discussed before by 
people much smarter about this than I.