Re: a quest for a better scheduler

[Ingo Molnar]

On Tue, 3 Apr 2001, Mike Kravetz wrote:

> [...] Currently, in this implementation we only deviate from the
> current scheduler in a small number of cases where tasks get a boost
> due to having the same memory map.

thread-thread-affinity pretty much makes it impossible to use a priority
queue. This 'small number of cases' is actually a fundamental issue: can
the 'goodness()' function be an arbitrary function of:

	goodness(process_prev,process_next) := f(process_prev,process_next)

, or is the queue design restricting the choice of goodness() functions?
Priority queues for example restrict the choice of the goodness() function
to subset of functions:

	goodness(process_prev,process_next) := f(process_next);

this restriction (independence of the priority from the previous process)
is a fundamentally bad property, scheduling is nonlinear and affinity
decisions depend on the previous context. [i had a priority-queue SMP
scheduler running 2-3 years ago but dropped the idea due to this issue.]
IMO it's more important to have a generic and flexible scheduler, and
arbitrary, nonnatural restrictions tend to bite us later on.

one issue regarding multiqueues is the ability of interactive processes to
preempt other, lower priority processes on other CPUs. These sort of
things tend to happen while using X. In a system where process priorities
are different, scheduling decisions cannot be localized per-CPU
(unfortunately), and 'the right to run' as such is a global thing.

> Can someone tell me what a good workload/benchmark would be to examine
> 'low thread count' performance? [...]

lmbench's lat_ctx for example, and other tools in lmbench trigger various
scheduler workloads as well.

	Ingo