[lkml]   [2003]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    SubjectRe: [patch] "HT scheduler", sched-2.5.63-B3

    On Fri, 28 Feb 2003, Andrew Morton wrote:
    > >
    > > Andrew, if you drop this patch, your X desktop usability drops?
    > hm, you're right. It's still really bad. I forgot that I was using distcc.
    > And I also forgot that tbench starves everything else only on CONFIG_SMP=n.
    > That problem remains with us as well.

    Andrew, I always thought that the scheduler interactivity was bogus, since
    it didn't give any bonus to processes that _help_ interactive users
    (notably the X server, but it could be other things).

    To fix that, some people nice up their X servers, which has its own set of

    How about something more like this (yeah, untested, but you get the idea):
    the person who wakes up an interactive task gets the interactivity bonus
    if the interactive task is already maxed out. I dunno how well this plays
    with the X server, but assuming most clients use UNIX domain sockets, the
    wake-ups _should_ be synchronous, so it should work well to say "waker
    gets bonus".

    This should result in:

    - if X ends up using all of its time to handle clients, obviously X will
    not count as interactive on its own. HOWEVER, if an xterm or something
    gets an X event, the fact that the xterm has been idle means that _it_
    gets a interactivity boost at wakeup.

    - after a few such boosts (or assuming lots of idleness of xterm), the
    process that caused the wakeup (ie the X server) will get the
    "extraneous interactivity".

    This all depends on whether the unix domain socket code runs in bottom
    half or process context. If it runs in bottom half context we're screwed,
    I haven't checked.

    Does this make any difference for you? I don't know what your load test
    is, and considering that my regular desktop has 4 fast CPU's I doubt I can
    see the effect very clearly anyway ("Awww, poor Linus!")

    NOTE! This doesn't help a "chain" of interactive helpers. It could be
    extended to that, by just allowing the waker to "steal" interactivity
    points from a sleeping process, but then we'd need to start being careful
    about fairness and in particular we'd have to disallow this for signal


    ===== kernel/sched.c 1.161 vs edited =====
    --- 1.161/kernel/sched.c Thu Feb 20 20:33:52 2003
    +++ edited/kernel/sched.c Wed Mar 5 19:09:45 2003
    @@ -337,8 +337,15 @@
    * boost gets as well.
    p->sleep_avg += sleep_time;
    - if (p->sleep_avg > MAX_SLEEP_AVG)
    + if (p->sleep_avg > MAX_SLEEP_AVG) {
    + int ticks = p->sleep_avg - MAX_SLEEP_AVG + current->sleep_avg;
    p->sleep_avg = MAX_SLEEP_AVG;
    + if (ticks > MAX_SLEEP_AVG)
    + ticks = MAX_SLEEP_AVG;
    + if (!in_interrupt())
    + current->sleep_avg = ticks;
    + }
    p->prio = effective_prio(p);
    enqueue_task(p, array);
    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: 2005-03-22 13:33    [W:0.022 / U:5.692 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site