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

From: Nick Piggin
Date: Thu Jul 08 2004 - 20:47:40 EST


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.
-
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/