Con Kolivas wrote:
On Saturday 07 January 2006 16:27, Mike Galbraith wrote:
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_
:)
Glad you've seen why I put the uninterruptible sleep logic in there. In
essence this is why the NFS client interactive case is not as nice - the NFS
code doesn't do "work on behalf of" a cpu hog with the TASK_UNINTERRUPTIBLE
state. The uninterruptible sleep detection logic made a massive difference to
interactivity when cpu bound tasks do disk I/O.
TASK_NONINTERACTIVE doesn't mean that the task is a CPU hog. It just
means that this sleep should be ignored as far as determining whether
this task is interactive or not.
Also, compensation for uninterruptible sleeps should be handled by the
"fairness" mechanism (i.e. time slices and the active/expired arrays)
not the "interactive response" mechanism. In other words, doing a lot
of uninterruptible sleeps is (theoretically) not a sign that the task is
interactive or for that matter that it's non interactive so
(theoretically) should just be ignored. That bad things happen when it
isn't needs explaining.
I see two possible reasons:
1. Audio/video streamers aren't really interactive but we want to treat
them as such (to ensure they have low latency). The fact that they
aren't really interactive may mean that the sleeps they do between runs
are uninterruptible and if we don't count uninterruptible sleep we'll
miss them.
2. The X server isn't really a completely interactive program either.
It handles a lot of interactive on behalf of interactive programs (which
should involve interactive sleeps and help get it classified as
interactive) but also does a lot of non interactive stuff (which can be
CPU intensive and make it loose points due to CPU hoggishness) which
probably involves uninterruptible sleep. The combination of ignoring
the uninterruptible sleep and the occasional high CPU usage rate could
result in losing too much bonus with consequent poor interactive
responsiveness.
So it would be interesting to know which programs suffered badly when
uninterruptible sleep was ignored? This may enable an alternate
solution to be found.
In any case and in the meantime, perhaps the solution is to use
TASK_NONINTERACTIVE where needed but treat
TASK_INTERRUPTIBLE|TASK_NONINTERACTIVE sleep the same as
TASK_UNINTERRUPTIBLE sleep instead of ignoring it?
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]
