O(1) scheduler questions + bug

Hi all

I started writing this email a while ago, the Doom III trailer example/bug has
prompted me to finish it.

Firstly, in -mm MAX_SLEEP_AVG defaults to 10 seconds. This means that a new
interactive task has a relatively low priority for nearly 5 seconds which feels
too long in practise. (eg start ogg123, music starts, switch desktop, music
skips) I think that MAX_SLEEP_AVG should be reduced to allow the scheduler to
react quicker.

Secondly, if there are (hypothetically) two interactive tasks, one repeatedly
works for 10ms and then sleeps for 90ms, and the other works for 45ms and
sleeps for 55ms, then they get the same maximum priority even though one is
"more interactive" than the other (using 10% of CPU rather than 45%). 

Has this been considered in the design of the effective_prio function? Does it
matter?

Finally, playing the Doom III trailer with mplayer results in mplayer's
priority slowly increasing to the maximum and therefore becoming
non-interactive, which means a CPU hog (perl -e 'while (1) {}') can cause the
audio/video playback to skip.  Mplayer consumes about 25% of CPU, X consumes
about 10%. (measured with top)

I'm currently using 2.5.69-mm2, Celeron 333, pre-empt.

Charlie