Re: # CONFIG_PREEMPT is not set
Oliver,
That does clear things up a bit, even if it is quite a bit to take in...
Previous to applying the realtime-lsm patches, audio recording/playback with multi-track hard disk recorders such as Ardour was very laggy and the audio skipped with more than 3 or so tracks. After I installed the new kernel, however, I have benchmarked it to around 20-odd tracks simultaneously playing audio and there was no skipping or patchyness.
I assumed before your explanation that the realtime-lsm patch simply enabled faster access to studio-specific audio hardware (such as my Delta 1010 PCI card/outboard).
It is apparently though different from the Preempt patches...
I think the reason I thought they were related is in the kernel configuration (I used menuconfig), under the "Kernel Pre-emption" section was "No pre-emption", a couple of others (cant remember off my head) and "Realtime Latency" :)
James
Oliver Korpilla <Oliver.Korpilla@gmx.de> wrote :
> james@total-carnage.org
> schrieb:
> > Is Realtime-lsm the same thing? I'm assuming no, as I have realtime-lsm on
> a 2.6.11 custom-built kernel for using a recording studio with...
>
> No, there is a mixup of name meanings here.
>
> Realtime priorities under Linux are priorities that are higher than that
> of any other user process. Linux offers 99 levels of those. If a process
> is elevated to such a high priority it will not have to compete for the
> CPU with other, non-realtime processes, and is therefore mostly safe
> from having to long pauses in playing back an audio file or recording one.
>
> LSM are the Linux Security Modules. This is a framework for fine-grained
> security models (beyond the user-or-root model). Because elevating a
> process to a RT prio needs root or acquiring a "capability" to
> increase
> a process' prio (only root usually can do that), there is this patch to
> allow standard programs to elevate themselves without being run by root.
>
> BTW: This is useful for playing and recording audio, e.g., but
> introduces a security risk by allowing normal processes to hog the CPU
> and starve the system from resources. But normally that's not a problem
> for you, except you have an 0wn3d user account (got "hacked" by some
>
> script kiddies) or have a very stupid application.
>
> "Real" realtime support like introduced with the preempt patches is
> not
> simply changing priorities. That stays the same. It enables you to
> switch between processes faster if a more important process becomes
> runnable. Usually all other processes must wait while one process
> executes a system call like read() on a device or open() on a file or
> whatever. With preempt the more important process only needs to wait if
> the process is in a very critical section of the kernel code where it is
> explicitly forbidden to be preempted. The preempt patch therefore lowers
> the "average latency" (the time you have to wait for the most
> important
> process to execute) and allows smoother multimedia.
>
> Any questions left? Hope I didn't overwhelm you - it's a bit hard to
> explain.
>
> With kind regards,
> Oliver Korpilla
>
>
> --
> To UNSUBSCRIBE, email to debian-amd64-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
___________________________________
Sent Using: Total Carnage WebMail, with NOCC, http://nocc.sourceforge.net
Reply to: