Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Nov 2007 20:23:22 +0100
From:      Kris Kennaway <kris@FreeBSD.org>
To:        Yar Tikhiy <yar@comp.chem.msu.su>
Cc:        jroberson@chesapeake.net, freebsd-current@freebsd.org
Subject:   Re: SCHED_ULE & niceness / rtprio
Message-ID:  <4743342A.10507@FreeBSD.org>
In-Reply-To: <20071120141403.GE81260@comp.chem.msu.su>
References:  <20071120141403.GE81260@comp.chem.msu.su>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4743342A.10507>