From owner-freebsd-current@FreeBSD.ORG Tue Nov 20 14:40:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7442916A418; Tue, 20 Nov 2007 14:40:42 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 8E6C313C48A; Tue, 20 Nov 2007 14:40:39 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id lAKEE5Pw050212; Tue, 20 Nov 2007 17:14:05 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id lAKEE4Xf050208; Tue, 20 Nov 2007 17:14:04 +0300 (MSK) (envelope-from yar) Date: Tue, 20 Nov 2007 17:14:03 +0300 From: Yar Tikhiy To: freebsd-current@freebsd.org Message-ID: <20071120141403.GE81260@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Cc: Subject: SCHED_ULE & niceness / rtprio X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 14:40:42 -0000 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