[lkml]   [2007]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ck] Re: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler
    On Monday 05 March 2007 22:59, Al Boldi wrote:
    > Markus Törnqvist wrote:
    > > On Mon, Mar 05, 2007 at 08:34:45AM +0300, Al Boldi wrote:
    > > >Ok, gears is smooth when you run "make -j4", but with "nice make -j4",
    > > > gears becomes bursty. This looks like a problem with nice-levels. In
    > > > general, looking subjectively at top d.1, procs appear to show
    > > > jerkiness when nice'd.

    I wouldn't place much value on what you can see just from looking at top.
    Gears just isn't an interactive task and just about anything but gears would
    be a better test case since its behaviour varies wildly under different
    combinations of graphics cards, memory bandwidth, cpu and so on. I'm not even
    sure what you're trying to prove with gears. If it's to see "smooth
    behaviour" under load then gears is not the thing to do it with. Maybe
    unbuffered live video on xawtv or something? Perhaps even capturing video
    where you know what the cpu usage will be of the video codec you're using.
    Say you knew xvid at a fixed bitrate required 30% cpu to encode a live video
    then you could see if it did it real time with a make -j2 running assuming
    you don't run out of disk bandwidth and so on. Or something that required 75%
    cpu and you ran a nice -19 make -j4. Or even try interbench and fiddle with
    the nice values and size of the loads since those options exist and see what
    the latencies and %desired cpu are. By default without arguments interbench
    looks for unfair scheduling and finds plenty of it in other scheduler
    designs. Either way your testcase must mean something to you.

    > > Don't use glxgears, please. Ever. Unless you want meaningless gears.

    That I definitely agree with.

    > > It displays totally erratic behaviour anyway, and does sched_yield
    > > (strace tells us this) which means IT GIVES UP ITS TIME TO RUN, ie yields
    > > the cpu to someone else.
    > I just strace'd it here. It doesn't show any yield in the mesa-5.0
    > version. Which version are you using?

    Curious. On a machine with onboard intel graphics (915 driver), and on an ATI
    r200 dri based driver I can see yields. Yet with the nvidia driver I see no
    yields. This sched_yield seems to be more done by the driver rather than the
    application. That would cause woeful performance. How odd that modern drivers
    out there today are still using this basically defunct unix function. No, I'm
    not interested in getting into a discussion of the "possible" uses of
    sched_yield. That's been done to death many times before.

    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-03-05 13:33    [W:0.023 / U:2.884 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site