lkml.org 
[lkml]   [2006]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] sched: Fix adverse effects of NFS client on interactive response
    At 12:11 PM 1/7/2006 +1100, Peter Williams wrote:

    >Is that patch complete? (This is all I got.)

    Yes.

    >--- linux-2.6.15/kernel/sched.c.org Fri Jan 6 08:44:09 2006
    >+++ linux-2.6.15/kernel/sched.c Fri Jan 6 08:51:03 2006
    >@@ -1353,7 +1353,7 @@
    >
    > out_activate:
    > #endif /* CONFIG_SMP */
    >- if (old_state == TASK_UNINTERRUPTIBLE) {
    >+ if (old_state & TASK_UNINTERRUPTIBLE) {
    > rq->nr_uninterruptible--;
    > /*
    > * Tasks on involuntary sleep don't earn
    >@@ -3010,7 +3010,7 @@
    > unlikely(signal_pending(prev))))
    > prev->state = TASK_RUNNING;
    > else {
    >- if (prev->state == TASK_UNINTERRUPTIBLE)
    >+ if (prev->state & TASK_UNINTERRUPTIBLE)
    > rq->nr_uninterruptible++;
    > deactivate_task(prev, rq);
    > }
    >
    >In the absence of any use of TASK_NONINTERACTIVE in conjunction with
    >TASK_UNINTERRUPTIBLE it will have no effect.

    Exactly. It's only life insurance.

    > Personally, I think that all TASK_UNINTERRUPTIBLE sleeps should be
    > treated as non interactive rather than just be heavily discounted (and
    > that TASK_NONINTERACTIVE shouldn't be needed in conjunction with it) BUT
    > I may be wrong especially w.r.t. media streamers such as audio and video
    > players and the mechanisms they use to do sleeps between cpu bursts.

    Try it, you won't like it. When I first examined sleep_avg woes, my
    reaction was to nuke uninterruptible sleep too... boy did that ever _suck_ :)

    I'm trying to think of ways to quell the nasty side of sleep_avg without
    destroying the good. One method I've tinkered with in the past with
    encouraging results is to compute a weighted slice_avg, which is a measure
    of how long it takes you to use your slice, and scale it to match
    MAX_SLEEPAVG for easy comparison. A possible use thereof: In order to be
    classified interactive, you need the sleep_avg, but that's not enough...
    you also have to have a record of sharing the cpu. When your slice_avg
    degrades enough as you burn cpu, you no longer get to loop in the active
    queue. Being relegated to the expired array though will improve your
    slice_avg and let you regain your status. Your priority remains, so you
    can still preempt, but you become mortal and have to share. When there is
    a large disparity between sleep_avg and slice_avg, it can be used as a
    general purpose throttle to trigger TASK_NONINTERACTIVE flagging in
    schedule() as negative feedback for the ill behaved. Thoughts?

    -Mike

    -
    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/

    \
     
     \ /
      Last update: 2006-01-07 06:29    [W:0.024 / U:1.464 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site