Subject: Re: [linux-audio-dev] rough rough ladspa docs
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Mon May 15 2000 - 13:01:38 EEST
On Mon, 15 May 2000, Paul Barton-Davis wrote:
>
> KERNEL_CAPABLE makes some additional ideas pop up, and i think these
> are valid (no library calls, no math calls etc.)
>
> **** BUT **** floating point code is NOT legal inside the Linux
> kernel, so this is probably a pretty redundant idea. The kernel does
> not save/restore FP flags, and thus if it uses the FPU, it can destroy
> user-level FP context when it returns to a process that was using the
> FPU. You might have thought someone would come up with a patch for
> this, but to date, AFAIK nobody has ever had a need to do so.
I am by no means a kernel expert, but as far I recall from reading some
RTLinux docs , there are macros which save/restore the FPU flags
in your code.
I don't know if they exist too on the standard kernel.
But whit these, if would be trivial to make kernel FPU code:
in your run() function you simply do
save_FPU_flags()
do DSP stuff
restore_FPU_flags()
and if this is not enough: (because other IRQ routines may preempt your code)
save_FPU_flags()
distable IRQs
do DSP stuff
enable IRQs
restore_FPU_flags()
Assuming that you use small latencies (<5ms) (why else would you use kernel code
for doing DSP stuff, except for getting rock-solid timing ? :-) )
and use less than 100% of the CPU,
every few ms , there will be a window where the CPU is free to do usual stuff,
the mouse pointer will not stall or move in a choppy way, since these
interruptions are very short ( 1 / 5ms = 200Hz )
and just the same kind of interruptions do happen in userspace when using
SCHED_FIFO processes.
(try to run latencytest with a 32-64KB audio buffersize and then mouse pointer
movements will become quite choppy, since the SCHED_FIFO process
blocks you for 80% of the time every 100-200ms.
(That means the position update is about 5-10times/sec which is not enough
for fluid movement)
>
> increasing the size of the stack could also cause RT delays. the claim
> must really be:
>
> (1) The plugin must not use malloc(), free() or other operations
> that cause an increase in the size of the heap OR the stack.
> All memory used must already have been claimed by the process,
> either via previous calls to increase the heap size, or
> through the existence of a large enough stack.
>
> note that under linux, calling brk(2) does NOT allocate memory to a
> process. the pages are only allocated when they are touched. this was
> the subject of considerable discussion on linux-kernel recently.
I fully agree, RT programming is different from non-RT stuff.
Benno.
This archive was generated by hypermail 2b28 : Mon May 15 2000 - 12:45:58 EEST