[lkml]   [2007]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Ten percent test
    On Sunday 08 April 2007, Ingo Molnar wrote:
    >* Gene Heskett <> 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
    > commit 5ce74abe788a26698876e66b9c9ce7e7acc25413
    > Author: Mike Galbraith <>
    > 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.)

    Actually, its an XP2800 Athlon, 333 fsb, gig of memory. And I was all
    enthusiastic about this until amanda's nightly run started, at which
    point I started losing control for quite long periods, 30+ seconds at a
    time. Up till then I thought we had it made. In this regard, Cons
    patches were enough better to notice it right away, lags were 1-2 seconds

    That seems to be the killer loading here, building a kernel (make -j3)
    doesn't seem to lag it all that bad. One session of gzip -best makes it
    fall plumb over though, which was a disappointment.

    But, I could live with this.

    Now if I could figure out a way to nail dm_mod down to a fixed LANANA
    approved address, I just got bit again, because enabling pktcdvd caused a
    MAJOR switch, only from 253 to 252 but tar thinks the whole 45GB is all
    new again. So since it, dm_mod, no longer carries the experimental
    label, lets put that patch back in and be done with this particular
    hassle once and for all. If I had known that using LVM2 was going to be
    such a pain in the ass just with this item alone, I wouldn't have touched
    it with a 50 foot fiberglass pole. Or does this SOB effect normal
    partition mountings too? I don't know, and the suggested fixes from
    David Dillow I put in /etc/modprobe.conf are ignored for dm_mod, and when
    extended to pktcdvd, cause pktcdvd to fail totally.

    Mmm??, can I pass an 'option dm_mod major=238' as a kernel argument & make
    it work that way? This is extremely frustrating as it is now.

    > Ingo

    Cheers, Gene
    "There are four boxes to be used in defense of liberty:
    soap, ballot, jury, and ammo. Please use in that order."
    -Ed Howdershelt (Author)
    Real Programmers don't write in PL/I. PL/I is for programmers who can't
    decide whether to write in COBOL or FORTRAN.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-04-08 13:37    [W:0.027 / U:3.500 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site