Re: Ten percent test

[Rene Herman <rene.herman@gmail.com>]

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.