[LAU] Realtime, but many xruns when jack is started. Debian Etch

Florian Schmidt mista.tapas at gmx.net
Wed Oct 3 09:05:37 EDT 2007


On Wednesday 03 October 2007, Wolfgang Woehl wrote:
> Montag, 1. Oktober 2007 Marcos Guglielmetti:
> > @audio     -    rtprio   99
> > @audio     -    nice      -10
> > @audio     -    memlock     4000000
>
> Marcos, looking at these numbers (and variations of these on various
> netpages) I always wonder whether they are such a good idea: Wouldn't
> rtprio 99 allow for banzai processes to almost lock down the machine?
> Wouldn't memlock 4000000 (4GB) be like begging for a swapfest on standard
> 1GB/2GB machines? Isn't the whole point about limits.conf to effectively
> prevent processes from sucking in all resources? So that when realtime
> processes go havoc you'll be left with cycles and memory to survive the
> situation?

Yes,

one always assumes with settings like this, that the programs which are run 
are nicely behaved (e.g. jackd has a watchdog to kill its clients when they 
run havok)..

But whether you give one process RT prio 1 or 99 doesn't matter. It can always 
keep all SCHED_OTHER threads [the rest of your system, X, xterms, whatnot] 
from running at all effectively freezing the box (though in reality this is 
expected behaviout).

A typical method to counter this scenario would be to limit user processes to 
prio 98 and have another watchdog process runnning at prio 99. That watchdog 
would have another thread running at SCHED_OTHER and checks at regular 
intervals whether this thread got to run at all. If not -> take action and 
make e.g. all SCHED_FIFO threads in the system SCHED_OTHER so the user is 
able to recover from the situation.. There are several watchdogs available 
(including one from yours truly which needs an overhaul though)..

And yes, of course, you wouldn't want to give all system memory away to 
mlocking. You need some reserve..

Nice -10 otoh is pretty uncritical i guess.

Regards,
FLo



-- 
Palimm Palimm!
http://tapas.affenbande.org



More information about the Linux-audio-user mailing list