Date: Tue, 20 Nov 2007 14:08:49 -1000 (HST) From: Jeff Roberson <jroberson@chesapeake.net> To: Kris Kennaway <kris@freebsd.org> Cc: Yar Tikhiy <yar@comp.chem.msu.su>, freebsd-current@freebsd.org Subject: Re: SCHED_ULE & niceness / rtprio Message-ID: <20071120140752.C884@192.168.1.107> In-Reply-To: <4743342A.10507@FreeBSD.org> References: <20071120141403.GE81260@comp.chem.msu.su> <4743342A.10507@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 20 Nov 2007, Kris Kennaway wrote: > 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. I definitely knew about problems with positively niced tasks. I had not heard about the negative nice problems. This is my top priority as far as opensource goes. I've been unfortunately busy with other things however. I hope to get to this soon. Thanks, Jeff > > Kris > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071120140752.C884>