[linux-audio-user] kernel - using rtlimits, realtime_lsm

[Florian Schmidt]

On Wed, 21 Dec 2005 19:13:57 +0100
Christoph Eckert <ce at christeck.de> wrote:

> > 2.  Use the realtime_lsm module on an existing kernel - 
> > I've tried this, but I read it's no longer supported in the kernel
> > because of #3...
> 
> It's still supported and I run it on top of a recent 2.6.14.2 kernel. 
> Advantage: it's realtively simple to build and use. Usually you do not 
> need to rebuild a complete kernel, you only need to build that module 
> and load it.
> 
> OTOH, the RT-LSM module "only" makes it possible that non-root users get 
> access to realtime priviledges - it doesn't improve the latency of the 
> system itself, so...

Well, rtlimits doesn't do this either. 

The mechanism to gain realtime privs and the worst case scheduling
latencies of the kernel are two completely different issues.

For the former, there's the realtime-lsm and rtlimits which _only_
enable a non root user to do what a root user could do anyways.

For the latter, there's the -rt kernels, although the vanilla kernels
are quite usable these days, too.

> > 3.  Use rtlimits, which is already a part of the default kernel.
> 
> ...this is the right thing to do, I guess.

Well, it would be if the distributions supported this mechanism via the
usual PAM mechanism. As long as that is not given, a hack is needed, be
it either the realtime lsm or set_rtlimits.

> The default 2.6.14 kernel is much better for audio work than any kernel 
> before. If it is good enough for your work, why bother yourself with 
> kernel patching?

It is quite ok for most uses, especially when not going for ultra low
latencies (like 8 or 16 frames). Make sure you use the "(X) Preemptible
Kernel (Low-Latency Desktop)" setting though when building a vanilla
kernel (or make sure your distro builds it this way if you use a distro
provided kernel; check i.e. /proc/config.gz and/or write a mail to the
appropriate ML/maintainer). 

Also the -rt kernel, due to prioritizing the irq handler threads,
provides better RT "guarantees" if you want to call it that ;) I.e.
given that the scheduler works correct, and that you have setup the
priorities in your system correctly (and that jackd ant the clients are
well behaving RT programs), there's almost _no way_ that other system
activity might cause delays that produce xruns in turn, even with
ridiculously low latencies.

Regards,
Flo

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