> 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?