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
Mike Galbraith wrote:
> 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.

It's on my list of things to try.

> When I first examined sleep_avg woes, my
> reaction was to nuke uninterruptible sleep too... boy did that ever
> _suck_ :)

I look forward to seeing it. :-)

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

Sounds like the kind of thing that's required. I think the deferred
shift from active to expired is safe as long as CPU hogs can't exploit
it and your scheme sounds like it might provide that assurance. One
problem this solution will experience is that when the system gets
heavily loaded every task will have small CPU usage rates (even the CPU
hogs) and this makes it harder to detect the CPU hogs. One slight
variation of your scheme would be to measure the average length of the
CPU runs that the task does (i.e. how long it runs without voluntarily
relinquishing the CPU) and not allowing them to defer the shift to the
expired array if this average run length is greater than some specified
value. The length of this average for each task shouldn't change with
system load. (This is more or less saying that it's ok for a task to
stay on the active array provided it's unlikely to delay the switch
between the active and expired arrays for very long.)

My own way around the problem is to nuke the expired/active arrays and
use a single priority array. That gets rid of the problem of deferred
shifting from active to expired all together. :-)

Peter
--
Peter Williams pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
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 07:36    [W:2.014 / U:0.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site