Subject: Re: [linux-audio-dev] info point on linux hdr
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Sat Apr 22 2000 - 17:42:31 EEST
On Sat, 22 Apr 2000, Jussi Laako wrote:
> Benno Senoner wrote:
>
> One big problem with Linux (and many other OS's) is lack of IO priorization.
> Any single user can easily "hang" the machine by generating large amount of
> disk IO and thus messing up any audio realtime processing.
SCHED_FIFO + lowlatency patches is immune from disk I/O .. see my pages.
>
> Good example of that was few days ago, when Acrobat Reader got wild on my
> laptop by starting to allocate and commit huge amounts of memory. Whole
> machine gone to unusable because kernel was swapping like nuts. Only way to
> get out of this infinite loop was to take battery out the machine...
this is called "disk trashing", swap can be a problem for low latency apps,
but mlockall() should prevent that you get don-deterministic times ..
anyway as soon your machine is in the TRASHING status, lowlatency or not,
the whole box gets unusable.
trashnig can occur if you run out of swap space (swap area full!), so that the
kernel has to throw away the pages of the loaded executables.
cure: increase swap area ( you can even add a swapfile on your partition, if you
don't have a spare partition available)
or alternatively trashing can happen when your working set model is bigger than
the available RAM. That means you have one or more programs which take for
example 100MB of virtual memory, but references ALL the 100MB continuously.
The kernel can do no other than swapping mem in and out to disk.
cure: buy more RAM.
Notice that RTOSes do not even support swap because of its non-determinism.
On linux we have the best of both worlds:
as long you don't get into the trashing state, SCHED_FIFO + mlockall() wil work
just nicely, even if your do very heavy disk I/O.
>
> I believe we need kernel feature to limit bus bandwidth single user or
> process can use. Kernel should limit time spent on swapping by putting
> memory hog process to hold. Same thing with IO hogs by dropping those
> processes down on scheduling list. This is also DOS type security bug.
> It would be nice to be able to give sound card driver higher priority
> compared to disk driver.
the swap watcher would be a nice, and it could be easily implemented by
gathering information about pagein and pageout frequencies of certain processes.
but again if you run out of swap space, (trashing case 1), then nothing , I say
nothing helps anymore. you are just executing your applications off the disk
instead from RAM. :-)
case2 may work, but it's hard to define a policy who is the "dangerous"
process. And the swap-watcher could make the wrong guessing, by stopping
exactly the app you are currently interested in.
:-)
As for IO hogs, the problem is that they execute in kernel most time, therefore
regular processes suffer big.
One solution could be to let the GUI and other apps run with higher
priority,but then disk IO throughtput could suffer when you scroll very fast
on your editor etc. It's not an easy task, because we audio folks, need
ALL features available simultaneously, at full speed, a simply unsolvable
problem from a technical POV.
Anyway with Linux we come pretty close to the ideal situation
(anone remembers formatting floppyis in a DOS shell under Windows ?,
the machine stalls almost entirely while only formatting a 1.4MB surface,
(actually the problem lies in BIOS calls which have to switch continuously
back and forth from 32bit to 16bit mode, with Linux you can't even notice that
there is a disk formatting in progress :-) )
Benno.
This archive was generated by hypermail 2b28 : Sat Apr 22 2000 - 17:38:12 EEST