Re: [PATCH] sched: Fix adverse effects of NFS client on interactive response

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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                                   [email protected]

"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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux