linux-kernel - Re: Ten percent test

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: <20070409141516.GB11244@elte.hu>
Date:	Mon, 9 Apr 2007 16:15:16 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Rene Herman <rene.herman@...il.com>
Cc:	Mike Galbraith <efault@....de>,
	Gene Heskett <gene.heskett@...il.com>,
	linux-kernel@...r.kernel.org, Con Kolivas <kernel@...ivas.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Ten percent test

* Rene Herman <rene.herman@...il.com> wrote:

> To me, the example rather serves as confirmation of what Kolivas has 
> been saying; endlessly tweaking the tweaks isn't going anywhere.

but ... SD clearly regresses in some areas, so by that logic SD isnt 
going anywhere either?

note that i still like the basic idea about SD, that it is an experiment 
that if the only conceptual focus is on "scheduling fairness", we'll get 
a better scheduler. But for that to work out two things have to be done 
i think:

 - the code actually has to match that stated goal. Right now it
   diverges from it (it is not a "fair" scheduler), and it's not clear
   why.

note that SD at the moment produces ~10% more code in sched.o, and the 
reason is that SD is more complex than the vanilla scheduler. People 
tend to get the impression that SD is simpler, partly because it is a 
net linecount win in sched.c, but many of the removed lines are 
comments.

this "provide fairness" goal is quite important, because if SD's code is 
not only about providing fairness, what is the rest of the logic doing? 
Are they "tweaks", to achieve interactivity? If yes, why are they not 
marked as such? I.e. will we go down the _same_ road again, but this 
time with a much less clearly defined rule for what a "tweak" is?

note that under the interactivity estimator it is not that hard to 
achieve forced "fairness".

So _if_ we accept that scheduling must include a fair dose of heuristics 
(which i tend to think it has to), we are perhaps better off with an 
interactivity design that _accepts_ this fundamental fact and separates 
heuristics from core scheduling. Right now i dont see the SD proponents 
even _accepting_ that even the current SD code does include heuristics.

the other one is:

 - the code has to demonstrate that it can flexibly react to various 
   complaints of regressions.

(I identified a few problem workloads that we tend to care about and i 
havent seen much progress with them - but i really reserve judgement 
about that, given Con's medical condition.)

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