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