linux-kernel - Re: [ANNOUNCE/RFC] Really Fair Scheduler

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: <46DA1DBF.7090509@tmr.com>
Date:	Sat, 01 Sep 2007 22:19:43 -0400
From:	Bill Davidsen <davidsen@....com>
To:	Roman Zippel <zippel@...ux-m68k.org>
CC:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	peterz@...radead.org, Mike Galbraith <efault@....de>
Subject: Re: [ANNOUNCE/RFC] Really Fair Scheduler

Roman Zippel wrote:
> Hi,
> 
> On Fri, 31 Aug 2007, Ingo Molnar wrote:
> 
> Maybe I should explain for everyone else (especially after seeing some of 
> the comments on kerneltrap), why I reacted somewhat irritated on what 
> looks like such an innocent mail.
> The problem is without the necessary background one can't know how wrong 
> such statements as this are, the level of confidence is amazing though:
> 
>> Peter's work fully solves the rounding corner-cases you described as:
> 
> I'd expect Ingo to know better, but the more he refuses to answer my 
> questions, the more I doubt it, at least than it comes to the math part.
> 
The "math part" is important if you're doing a thesis defense, but 
demonstrating better behavior under some realistic load would probably 
be a better starting point. Maybe Ingo missed something in your math, 
and maybe he just didn't find a benefit.

The ck and sd schedulers developed over a long time of public use and 
redefinition of goals. The cfs developed faster, but still had months of 
testing and the benefit of rt experience. Your scheduler is more of a 
virgin birth, no slow public discussion before, no time yet for people 
to run it under real loads, you're seeing first impressions.

You dropped this on the world two days before a major US holiday, at the 
end of the summer when those of us not on vacation may be covering for 
those who are, did you expect Ingo to drop his regular work to look at 
your stuff? And do you think there are many people who can look at your 
math, and look at your code, and then have any clue how well it works in 
practice? I bet there aren't ten people in the world who would even 
claim to do that, and half of them are kidding themselves.

So give people a few weeks to see if the rounding errors you eliminated 
mean anything in practice. Faster context is nice, but it's not 
something most people count as their major problem. I did a *lot* of cfs 
vs. sd testing, not just all the glitch1 tests I posted here, lots of 
stuff I just send to Ingo, and lots of tests like IPCbench and NNTP 
server loading showed nothing. (That's good, it means cfs isn't worse 
than the old scheduler for those loads.) I played with the tuning, I 
even diddled the code a bit, without finding meaningful improvement, so 
your possibly better math may not change the overall behavior much.

I will wait until I post actual test results before I say any more.

-- 
Bill Davidsen <davidsen@....com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
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/