Re: SCHED_ULE & niceness / rtprio

Yar Tikhiy wrote:
> 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?

Others have reported it, but I don't know if Jeff has had time to 
investigate yet.

Kris