Re: [PATCH] V-3.0 Single Priority Array O(1) CPU Scheduler Evaluation

Peter Williams
2004-08-04T02:40:55Z

> William Lee Irwin III wrote:
>
>>>Aperiodic rotations defer movement until MAX_RT_PRIO's slot is evacuated.
>
>
> On Wed, Aug 04, 2004 at 11:36:59AM +1000, Peter Williams wrote:
>
>>Unfortunately, to ensure no starvation, promotion has to continue even
>>when there are tasks in MAX_RT_PRIO's slot.
>
>
> One may either demote to evict MAX_RT_PRIO immediately prior to
> rotation or rely on timeslice expiry to evict MAX_RT_PRIO. Forcibly
> evicting MAX_RT_PRIO undesirably accumulates tasks at the fencepost.

It's starting to get almost as complex as the current scheme :-)

>
>
> William Lee Irwin III wrote:
>
>>>The primary concern was that ticklessness etc. may require it to occur
>>>during context switches.
>
>
> On Wed, Aug 04, 2004 at 11:36:59AM +1000, Peter Williams wrote:
>
>>On a tickless system, I'd consider using a timer to control when
>>do_promotions() gets called. I imagine something similar will be
>>necessary to manage time slices?
>
>
> This is an alternative to scheduler accounting in context switches.
> Periodicity often loses power conservation benefits.

The timer would be deactivated whenever the number of runnable tasks for
the runqueue goes below 2. The whole thing could be managed from the
enqueue and dequeue functions i.e.

dequeue - if the number running is now less than two cancel the timer
and otherwise decrease the expiry time to maintain the linear
relationship of the interval with the number of runnable tasks

enqueue - if the number of runnable tasks is now 2 then start the time
with a single interval setting and if the number is greater than two
then increase the timer interval to maintain the linear relationship.

I'm assuming here that add_timer(), del_timer() and (especially)
mod_timer() are relatively cheap. If mod_timer() is too expensive some
alternative method could be devised to maintain the linear relationship.