Subject: Re: [linux-audio-dev] Linux Security Module for realtime audio
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Wed Dec 10 2003 - 22:24:46 EET
Paul Davis wrote:
>
>now, if the audio thread is burning so much CPU time that the GUI
>doesn't get to run, its certainly a problem. but step back - is it a
>problem you want to fix by raising the priority of the GUI thread so
>that it steals time from the audio thread? or even from a "disk
>butler" thread. no, i don't think so. it simply means that the user is
>asking too much from their current hardware (and/or that the s/w is
>badly implemented, but thats a different story).
>
Speaking about the disk butler thread, I don't know what kind of
priority ardour's one uses
but in LinuxSampler we experienced weird behaviour when running the disk
thread with
SCHED_FIFO/RR , even at low priorities.
The problem is the following: normally the disk thread calls read() to
read data from disk and
since read() must wait for the disk I/O subsystems it often relinquishes
the CPU and thus
is causing no problems to the other active processes.
But since in LinuxSampler we often hit a situation where most of the
initial parts of each
sample (that is streamed from disk) gets cached by the linux disk i/o
layer it means that
the read() call will very often read from the cache (thus doing a memory
copy) instead from disk.
This is good because it avoids many unnecessary disk accesses (otherwise
we would need
to write our own caching algorithm but since Linux works so well we used
the kernel's one).
But there is a weird side effect that arises when the disk thread runs
with real time priority.
Assume a not so fast CPU (with relatively low RAM bandwidth), when you
play many notes
at the same time where most of the streams are cached (because your RAM
is large enough to
cache most of the samples needed) then the disk thread will issue
read()s that will almost everytime
translate to memory copying (from the disk cache to the userspace buffer).
This means a substantial chunk of CPU is used (eg 20-30%) by the disk
thread to copy the data.
And since the disk thread is optimized to read() large segments from
disk in order to maximize bandwidth,
it could happen that it read()s let's say 100 (# of voices) x 200KB of
data = 20MB before going to sleep.
This could stall the machine for several dozen/hundreds msecs stalling
GUIs and making the overall usage
of the machine sluggish.
This is why I now run the diskthread without real time privileges
because if the above situation happens
it does not suck away precious CPU time (the disk thread always tries to
refill all ringbuffers until they are completely
full but that is not strictly needed) making the box unresponsive.
So in conclusion I'd say: don't run your disk butlers SCHED_FIFO/RR but
use nice(-10) or something alike.
Same for GUIs if you care about reaction speed of the GUI run it
nice(-10) because with nice you don't risk hogging
the machine because of a slow gfx card/drivers or because of a
suboptimal redrawing implementation.
cheers,
Benno
http://www.linuxsampler.org
This archive was generated by hypermail 2b28 : Wed Dec 10 2003 - 15:20:53 EET