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

From: William Lee Irwin III
Date: Wed Aug 04 2004 - 02:46:25 EST


William Lee Irwin III wrote:
>> 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.

On Wed, Aug 04, 2004 at 12:40:15PM +1000, Peter Williams wrote:
> It's starting to get almost as complex as the current scheme :-)

Compare it to the background scan of the queue if several (potentially
numerous) events whose handling has been deferred are to be processed
when timer device interrupts are delivered at irregular intervals, or
not at all.


William Lee Irwin III wrote:
>> This is an alternative to scheduler accounting in context switches.
>> Periodicity often loses power conservation benefits.

On Wed, Aug 04, 2004 at 12:40:15PM +1000, Peter Williams wrote:
> 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.

Naive schemes reprogram the timer device too frequently. Software
constructs are less of a concern. This also presumes that taking timer
interrupts when cpu-intensive workloads voluntarily yield often enough
is necessary or desirable. This is not so in virtualized environments,
and unnecessary interruption of userspace also degrades performance.


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