Re: SCHED_ULE & niceness / rtprio

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 <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <unistd.h>

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));
	}
}