linux-kernel - Re: Question about fair schedulers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070623152653.05ebac64@localhost>
Date:	Sat, 23 Jun 2007 15:26:53 +0200
From:	Paolo Ornati <ornati@...twebnet.it>
To:	Alberto Gonzalez <info@...bu.es>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Question about fair schedulers

On Sat, 23 Jun 2007 10:01:02 +0200
Alberto Gonzalez <info@...bu.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/