SCHED_ULE & niceness / rtprio

Hi all,

SCHED_ULE seems to do an unfair job to processes with low niceness
or with real-time priority.  Here are my observations:

A few days ago I noticed that music (played by Totem, Gnome's default
player) would pause for a fraction of second each time I did something
in X/Gnome, such as switched between windows, clicked on a link in
the web browser, etc.  Then I found that music was jerky only if
the player ran with a negative niceness or a real-time priority:
As soon as I returned it to niceness 0 and normal priority, sound
became totally seamless notwithstanding my activity in X.

The approximate value required for the effect to appear was niceness
as low as -5 or RT priority as high as 10; niceness -1 or rtprio 1
wasn't enough.

Curious, I substituted SCHED_4BSD for SCHED_ULE in my otherwise
GENERIC kernel, and the jerkiness of sound was gone irrespective
of the niceness or RT priority of the player.

To rule out other possible causes, I also tried kernels with SCHED_ULE
but without SMP or without debug stuff (INVARIANTS+WITNESS), but
the issue was there in both cases, unlike in the case of SCHED_4BSD.

Of course, X+Gnome+stuff isn't the clearest environment for debugging
schedulers, but multimedia apps are rather sensitive to scheduling
quality.  This case should be rather obvious:  When I click in an
inactive window, some processes are woken that have been idle.
After that the high-priority player isn't scheduled long enough for
the hardware audo buffer to drain, although it would be scheduled
soon if it had normal priority.

Did I hit a known issue?

-- 
Yar