Re: Ten percent test

[Ingo Molnar <mingo@elte.hu>]

* Gene Heskett <gene.heskett@gmail.com> wrote:

> That said, I am booted to the patch you sent me now, and this also is 
> a very obvious improvement, one I could easily live with on a long 
> term basis.  I haven't tried a kernel build in the background yet, but 
> I have sat here and played patience for about an hour, looking for the 
> little stutters, but never saw them.  So I could just as easily 
> recommend this one for desktop use, it seems to be working.  tvtime 
> hasn't had any audio or video glitches that I've noted when I was on 
> that screen to check on an interesting story, like the 102 year old 
> lady who finally got her hole in one, on a very short hole, but after 
> 90 years of golfing, she was beginning to wonder if she would ever get 
> one.  Not sure who bought at the 19th hole, HNN didn't cover that 
> traditional part.
> 
> So this patch also works.  And if it gets into mainline, at least 
> Con's efforts at proding the fixes needed will not have been in vain.

thanks for testing it! (for the record, Gene tested sched-mike-4.patch, 
which is Mike's patch from 4 days ago.)

> My question then, is why did it take a very public cat-fight to get 
> this looked at and the code adjusted?  Its been what, nearly 2 years 
> since Linus himself made a comment that this thing needed fixed.  The 
> fixes then done were of very little actual effectiveness and the 
> situation then has gradually deteriorated since.

this is pretty hard to get right, and the most objective way to change 
it is to do it testcase-driven. FYI, interactivity tweaking has been 
gradual, the last bigger round of interactivity changes were done a year 
ago:

 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.

It's really hard to judge interactivity subjectively, so we rely on 
things like interbench (written by Con) - in which testsuite the 
upstream scheduler didnt fare all that badly, plus other testcases 
(thud.c, game_sim.c, now massive_inter.c, fiftyp.c and chew.c) and all 
the usual test-workloads. This is admittedly a slow process, but it 
seems to be working too and it also ensures that we dont regress in the 
future. (because testcases stick around and do get re-tested)

your system seems to also be a bit special because you 1) drive it to 
the absolute max on the desktop but you do not overload it in obvious 
ways (i.e. your workloads are pretty fairly structured) 2) it's a bit 
under-powered (single-CPU 800 MHz CPU, right?) but not _too_ 
underpowered - so i think you /just/ managed to hit 'the worst' of the 
current interactivity estimator: with important tasks both being just 
above and just below 50%. Believe me, on all ~10 systems i use 
regularly, Linux interactivity of the vanilla scheduler is stellar. (And 
that includes a really old 500 MHz one too with FC6 on it.)

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