linux-kernel - Re: is RSDL an "unfair" scheduler too?

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: <20070317163434.GB30162@elte.hu>
Date:	Sat, 17 Mar 2007 17:34:34 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Con Kolivas <kernel@...ivas.org>
Cc:	Serge Belyshev <belyshev@...ni.sinp.msu.ru>,
	Al Boldi <a1426z@...ab.com>, Mike Galbraith <efault@....de>,
	linux-kernel@...r.kernel.org, Nicholas Miell <nmiell@...cast.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: is RSDL an "unfair" scheduler too?

* Con Kolivas <kernel@...ivas.org> wrote:

> Ok but please look at how it appears from my end (illness aside).

( i really think we should continue this debate after you get better. 
  Everything looks much darker when you are ill! )

> You initially said you were pleased with this design.

I said that 2 years ago about the staircase scheduler and i am still 
saying this about RSDL today. That doesnt make my position automatically 
correct though :-) For example i wrote and maintained the 4g:4g patchset 
for over 2 years and still that was no guarantee of it making sense 
upstream ;) And it was a hell of a lot of work (much uglier and nastier 
work than any scheduler hacking and tuning, believe me), and it was 
thrown away as a cute but unnecessary complication we dont need. So 
what? To me what matters is the path you walk, not the destination you 
reach.

in terms of RSDL design, i like it, still i'm kind of asking myself 
'couldnt something in this direction be done in a much simpler and less 
revolutionary way'? For example couldnt we introduce per-priority level 
timeslice quotas in the current scheme as well, instead of the very 
simplistic and crude STARVATION_LIMIT approach? Furthermore, couldnt we 
make the timeslices become smaller as the runqueue length increases, to 
make starvation less of a problem? It seems like the problem cases with 
the current scheduler arent so much centered around the interactivity 
estimator, it is more that timeslices get distributed too coarsely, 
while RSDL distributes timeslices in a more finegrained way and is thus 
less suspect to starvation under certain workloads.

in any case, regardless the technical picture, i do get nervous when a 
group of people tries to out-shout clearly valid feedback like Mike's, 
and i'll try to balance such effects out a bit. _Of course_ those people 
that are not happy with the current scheduler have a higher likelyhood 
to try out another scheduler and be happy about it - but we should not 
allow that natural bias (which, btw., could easily be the _truth_, so 
i'm not assuming anything) to stand in the way of critical thinking. I 
also get slightly nervous about what appears to be dubious technical 
claims like "this is X's fault and if you rewrite X it will work much 
better so go away and do not stand in the way of progress" or "this new 
scheduler does away with all those ugly heuristics". I'm almost getting 
a reiser4 de ja vu :-/

we should really let this sit through in -mm for at least one more 
kernel iteration, let more folks be exposed to it and keep an eye on 
regression reports. [ An _eye_, not a machine gun ;-) ]

	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/