Date: Tue, 20 Nov 2007 17:14:03 +0300 From: Yar Tikhiy <yar@comp.chem.msu.su> To: freebsd-current@freebsd.org Subject: SCHED_ULE & niceness / rtprio Message-ID: <20071120141403.GE81260@comp.chem.msu.su>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071120141403.GE81260>