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

From: Peter Williams
Date: Sat Jan 07 2006 - 18:30:00 EST


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 pwil3058@xxxxxxxxxxxxxx

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