Mike Galbraith wrote:
At 10:13 AM 1/6/2006 +1100, Peter Williams wrote:
Mike Galbraith wrote:
At 10:31 PM 1/5/2006 +1100, Peter Williams wrote:
Mike Galbraith wrote:
At 08:51 AM 1/5/2006 +1100, Peter Williams wrote:
I think that some of the harder to understand parts of the
scheduler code are actually attempts to overcome the undesirable
effects (such as those I've described) of inappropriately
identifying tasks as interactive. I think that it would have been
better to attempt to fix the inappropriate identifications rather
than their effects and I think the prudent use of
TASK_NONINTERACTIVE is an important tool for achieving this.
IMHO, that's nothing but a cover for the weaknesses induced by
using exclusively sleep time as an information source for the
priority calculation. While this heuristic does work pretty darn
well, it's easily fooled (intentionally or otherwise). The
challenge is to find the right low cost informational component,
and to stir it in at O(1).
TASK_NONINTERACTIVE helps in this regard, is no cost in the code
where it's used and probably decreases the costs in the scheduler
code by enabling some processing to be skipped. If by its judicious
use the heuristic is only fed interactive sleep data the heuristics
accuracy in identifying interactive tasks should be improved. It
may also allow the heuristic to be simplified.
I disagree. You can nip and tuck all the bits of sleep time you
want, and it'll just shift the lumpy spots around (btdt).
Yes, but there's a lot of (understandable) reluctance to do any major
rework of this part of the scheduler so we're stuck with nips and
tucks for the time being. This patch is a zero cost nip and tuck.
Color me skeptical, but nonetheless, it looks to me like the mechanism
might need the attached.
Is that patch complete? (This is all I got.)
--- 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. 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.
On the subject of nip and tuck, take a look at the little proggy posted
in thread [SCHED] wrong priority calc - SIMPLE test case. That testcase
was the result of Paolo Ornati looking into a real problem on his
system. I just 'fixed' that nanosleep() problem by judicious
application of TASK_NONINTERACTIVE to the schedule_timeout(). Sure, it
works, but it doesn't look like anything but a bandaid (tourniquet in
this case:) to me.
-Mike
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]
