Re: Maximum frequency of re-scheduling (minimum time quantum ) que stio n

[Nick Piggin <nickpiggin@yahoo.com.au>]

Peter Williams wrote:
> Povolotsky, Alexander wrote:
> 
>> Hi Peter,
>>
>>
>>> By freeing "time slice"s from their involvement in active/expired 
>>> priority array switching etc., the various single priority array 
>>> schedulers (e.g. Con Kolivas's staircase scheduler and my SPA "pb" 
>>> and "eb" schedulers) that are under development raise the possibility 
>>> of allowing the time slice for SCHED_RR tasks to be different to that 
>>> of ordinary tasks or even for it to be set separately for each 
>>> SCHED_RR task.  Whether this is desirable or not is another question.
>>
>>
>>
>> IMHO (I am new in Linux),- if this functionality could be either 
>> optionally
>> configured at compile time or be optionally invokable at run time (or
>> combination of both) - why not to have it ? - this addition enhances 
>> choices
>> of scheduling,
>> which is good.
>>
>> Is there a chance such functionality will make into Linux 2.6 as a 
>> patch (at
>> some later time) ?
> 
> 
> Not until the current scheduler is replaced with a single priority array 
> scheduler.  However, if there's enough interest, I could add this 
> functionality to the CPU scheduler evaluation patch so that people could 
> experiment with it (BUT it would be at the bottom of my to do list).

You are mistaken. The current scheduler only uses a single array
for realtime tasks. Functionality would be trivial to implement
now.

> 
>>
>> By the way - what is the "mechanism" of decision making process (among 
>> Linux
>> kernel developers) on such things ?
> 
> 
> I'll leave this question to someone more knowledgeable.
> 

I'd defer a final decision to others more knowlegeable of course
(Ingo, Andrew, Linus?), however it would be almost out of the
question to do a wholesale replacement in 2.6.

However well tested your scheduler might be, it needs several
orders of magnitude more testing ;) Maybe the best we can hope
for is compile time selectable alternatives.