From owner-freebsd-current@FreeBSD.ORG Mon Jan 21 15:53:50 2008 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 BCF3716A468 for ; Mon, 21 Jan 2008 15:53:50 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.235]) by mx1.freebsd.org (Postfix) with ESMTP id 76AA213C457 for ; Mon, 21 Jan 2008 15:53:50 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so1046246nzf.13 for ; Mon, 21 Jan 2008 07:53:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=FYj1ro54ubV7UYOxycHFwXO9YVR/YgG1Y7FaO9TGEEA=; b=OjCAz0EYpU+lgmtK7q42N6PMdtOE3Z1HX+GlV+6RawUc1wgi1z1kqzpdRIxcOQ6xPU7LyucGavywcmCTwSKy30RF6OSD13CfYZfbN/epilMajy/ljBQpATQA2z+f3PT0CFrVpPKXN5rGs+l3l08rTkhO5Tu0hBoF6mjcph3xZW8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ws/UKxdAizbT/dn1Pt4YL1ZbuqCsaDxn6nNeLW9PYpSvL70arj/YpJV62Onx2lf/TP0OJ/aoUniV58DmvIy2zxnmzTpkaVfk9BZycCOmE/ujvUso2fhj1oExJOURph+hF2b+a8sk0fo3+/hl8kALyp7KaQPgRHCSf+mvOAiUfP8= Received: by 10.141.15.19 with SMTP id s19mr4537237rvi.205.1200930829165; Mon, 21 Jan 2008 07:53:49 -0800 (PST) Received: by 10.141.68.21 with HTTP; Mon, 21 Jan 2008 07:53:49 -0800 (PST) Message-ID: <2fd864e0801210753y3fc49cd5v67ca75e0376bdb21@mail.gmail.com> Date: Mon, 21 Jan 2008 23:53:49 +0800 From: Astrodog To: "Yar Tikhiy" In-Reply-To: <20080121122402.GA63088@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071120141403.GE81260@comp.chem.msu.su> <4743342A.10507@FreeBSD.org> <20080101185451.S957@desktop> <20080121122402.GA63088@comp.chem.msu.su> Cc: Jeff Roberson , freebsd-current@freebsd.org Subject: Re: 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: Mon, 21 Jan 2008 15:53:50 -0000 On Jan 21, 2008 8:24 PM, Yar Tikhiy wrote: > > On Tue, Jan 01, 2008 at 06:56:59PM -1000, Jeff Roberson wrote: > > 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 tried to reproduce this recently by running mplayer with various nice > > values while scrolling around a lot in firefox. This is on a 1.4ghz > > machine. I didn't encounter any problems. > > Well, scrolling around might not trigger the problem. The issue might > be seen, or heard, better when different processes are being woken up. > > > If anyone is having nice related problems with ULE I'd love a simple test > > case that shows it. I tried installing boinc which was mentioned in other > > threads but had trouble contacting the servers and getting it setup. > > Something simpler would be very beneficial. > > Today I've finally got a chance to update my workstation to the > latest HEAD and try again in order to see if your last patch has > any effect for my issue. Alas, it doesn't, sorry. > > My environment: GNOME 2 out of the box, namely as installed from > the gnome2-lite port. That includes Firefox and Totem player. > > What I did: was switching between windows of different apps (Firefox, > Terminal) via Alt+Tab, or between virtual desktops with some windows > on them using mouse, while playing an mp3 tune in the Totem player. > > What I also noticed was that assigning an idle priority to the > player makes the sound falter as well. I.e., the sound is smooth > only when the player runs at normal priority and zero, or numerically > greater, niceness. > > Lastly, I think I've found a simpler test case. Attached is a > proglet that essentially simulates the load pattern by waking up > periodically and doing dummy things. In my case (1GHz CPU,) 4-6 > instances of it running in the background are enough to make the > issue manifest itself: When I assign an RT/idle priority or negative > niceness to the player process, it starts to stutter, but as soon > as I return the player process to normal priority & niceness, it > plays fluently again. > > I haven't found a suitable detector other than a media player yet. > However, in my case, madplay is as good as Totem in detecting the > presumable scheduling problem, from which I infer that any audio > player will do, including command-line ones. Sorry, I can't test > this against mplayer now as my ADSL line is temporarily down and I > have to resort to dial-up, so downloading mplayer isn't an option > for me now. :-) > > -- > Yar > > #include > #include > #include > #include > #include > > const int n = 10 * 1024 * 1024; /* how many bytes of RAM to burn */ > const int v = 0; /* verbose flag */ > > int > main() > { > struct timespec ts0, ts; > char *p; > long dn, ds; > int i; > > for (;;) { > if (v) > clock_gettime(CLOCK_MONOTONIC, &ts0); > if ((p = malloc(n)) != NULL) { > for (i = 0; i < n; i++) > p[i] = (char)(i % 53); /* just a prime number */ > free(p); > } > if (v) { > clock_gettime(CLOCK_MONOTONIC, &ts); > ds = ts.tv_sec - ts0.tv_sec; > dn = ts.tv_nsec - ts0.tv_nsec; > if (dn < 0) { > ds--; > dn += 1000 * 1000 * 1000L; > } > if (dn < 0 || ds < 0) > abort(); > printf("last run took %ld.%09ld sec\n", ds, dn); > } > /* sleep 1-2 sec */ > usleep(1000 * 1000L + random() % (1000 * 1000L)); > > } > } > _______________________________________________ > 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" > Just to be sure I understand this correctly... the player stutters when you *decrease* its priority (Or increase its niceness) only?