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

[Peter Williams <pwil3058@bigpond.net.au>]

Nick Piggin wrote:
> 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.

OK.

> 
>>
>>>
>>> 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 ;)

I agree (not to mention more experimenting to find good default values 
for some of the control parameters).  I was just passing on someone 
else's question.

> Maybe the best we can hope
> for is compile time selectable alternatives.

I'm hoping that a lot of the current configurable parameters in my 
schedulers can become constants.  For most of them, the reason that they 
are now configurable is to make trying out different values easier (i.e. 
no need to recompile and reboot).

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce