Re: Ten percent test

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <[email protected]>
 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 <[email protected]>
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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux