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.
If the plugsched patches were included in -mm we could get wider testing
of alternative scheduling mechanisms. But I think it will take a lot of
testing of the new schedulers to allay fears that they may introduce new
problems of their own.
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]
