Re: Ten percent test

Rene Herman
2007-04-09T12:16:16Z

On 04/09/2007 06:23 AM, Mike Galbraith wrote:

> On Sun, 2007-04-08 at 20:51 +0200, Rene Herman wrote:

>> On 04/08/2007 12:41 PM, Ingo Molnar wrote:

>>> commit 5ce74abe788a26698876e66b9c9ce7e7acc25413
>>> Author: Mike Galbraith <efault@gmx.de>
>>> Date: Mon Apr 10 22:52:44 2006 -0700
>>>
>>> [PATCH] sched: fix interactive task starvation
>>>
>>> (and a few smaller tweaks since then too.)
>>>
>>> and that change from Mike responded to a testcase. Mike's latest changes
>>> (the ones you just tested) were mostly driven by actual testcases too,
>>> which measured long-term timeslice distribution fairness.
>>
>> Ah yes, that one. Here's the next one in that series:
>>
>> commit f1adad78dd2fc8edaa513e0bde92b4c64340245c
>> Author: Linus Torvalds <torvalds@g5.osdl.org>
>> Date: Sun May 21 18:54:09 2006 -0700
>>
>> Revert "[PATCH] sched: fix interactive task starvation"
>>
>> It personally had me wonder if _anyone_ was testing this stuff...
>
> Well of course not. Making random untested changes, and reverting
> them later is half the fun of kernel development.

The point ofcourse is that the very example Molnar quoted as an example
of responsible, testcase driven development was in fact hugely broken
and sat in the tree that way for 4 rc's.

To me, the example rather serves as confirmation of what Kolivas has
been saying; endlessly tweaking the tweaks isn't going anywhere. The
minute you tweak A, tweak B over there in corner C-Sharp falls flat on
its face.

Computers are horribly stupid and tend to fail most situations their
smart human programmers didn't specifically tell them about. If, as in
the case of a scheduler, the real-world demands on a piece of software
are so diverse that you cannot tell them about all possible situations
specifically, the only workable solution is to make them _predictable_
so that when hitting one of those special situations, the smart human
using the computer at least gets to know how to intervene if he feels
inclined to do so.

This turned into an interactivity thing, and while interactivity is in
fact better for a large majority of testers, that isn't what Kolivas'
scheduler is about. It's about predictability and leaving the dead-end
road of these endlesss tweaks, which then break previous tweaks, rinse,
repeat.

It's unfortunate that Kolivas is having health problems currently, but I
certainly do hope that his scheduler finds its way into _a_ -rc1. He
said it was done...

Rene.