Re: SCHED_ULE & niceness / rtprio

On Jan 21, 2008 8:24 PM, Yar Tikhiy <yar_at_comp.chem.msu.su> 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 <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));
>
>        }
> }
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>

Just to be sure I understand this correctly... the player stutters
when you *decrease* its priority (Or increase its niceness) only?