Re: Question about fair schedulers

[Paolo Ornati <ornati@fastwebnet.it>]

On Sat, 23 Jun 2007 10:01:02 +0200
Alberto Gonzalez <info@gnebu.es> wrote:

> I see. So you mean that in 90% of the cases the mainline scheduler behaves 
> better than fair schedulers, but when its "logic" fails it behaves much worse 
> (the other 10% cases)?

Yes and no... the "logic" is supposed to identify what processes are
somehow interactive and give them more priority / CPU time.

This makes the system behaves better when there are CPU hog processes
(like encoders etc...) because the interactive ones doesn't suffer too
much.

The big problem is that it can identify an almost CPU hog process as
interactive.... and giving him an insane amount of CPU starve the
others.

In my case it was "trancode", and I assure you... it wasn't funny.
Sometimes it happened that running it (at standard nice 0) made
the machine totally unusable!  (something like 30s to switch from X to
a virtual terminal... and I don't tell you how hard was doing login and
killing/renicing it).

So far I've seen these pathological behaviour only with trancode and
wine (only with particular programs I don't remember now).

But the fact is, the "interactivity estimator" is too fragile, and when
it fails it can do much damage.


Fair scheduler instead:
	- are robust
	- provide consistent behaviour
	- provide good interactivity within the bounds of fairness


> In my very simple test scenario the mainline scheduler 
> did behave much better.

Of course... because of the two competing processes the
"interactive" (for you) one needs 60%, that is more than it's 50% fair
share.

The real solution is to use nice levels so the scheduler doesn't have
to guess what process is more important.

And yes, programs/distributions should set good defaults for you... and
if they don't, just complain to them  :)

-- 
	Paolo Ornati
	Linux 2.6.22-rc5-g0864a4e2 on x86_64