Subject: Re: [linux-audio-dev] Disk use causes freezes
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed Aug 01 2001 - 16:12:45 EEST
if cp(1) reads more than 4K of a file at one time, I'd be
very suprised. however, it will tend to fill the disk cache.
if the disk cache can grow large enough on your system to cause the
kind of problems you observe then your system is misconfigured.
However, I note that you are running 2.2, and one of the major pieces
of work done between 2.2 and 2.4 was to drastically improve the
performance and behaviour of both VM in general and the disk cache in
particular. I would suggest that you try this under 2.4. I am fairly
certain you will see a dramatic improvement.
>Yes I have a swap space, and it looks like it is taking all the power of
>Linux under disk use (entire memory is filled with md5summed file and no
>room is left to other processes). It could be wise to take swap away if
>one is expected to use an audio editor in real-time, but that should not
>be the solution to the problem.
How can you do *anything* else? You, the user, have chosen to run 2 or
more processes that require more memory than you have available. Your
system has to put the data from the memory associated with one of them
into swap at least some of the time. It doesn't have any other choice;
you asked it to create this situation, or rather the programmer(s) of
the applications in question did because they wrote their code to use
memory as if there were no limits on it.
>The memory is filled with file data, so, would it help if read()/write()
>buffers would be locked? If yes, then all file accesses of audio programs
Any audio program that reads so much data from a file that it fills
physical memory is either totally broken (and yes, such programs
exist) or is being run on a system with an absurdly small amount of
memory.
An audiofile editor does not need to do:
buf = malloc (audiofile->length);
read (audiofile->fd, buf, audiofile->length);
and writing code that works this way is both stupid and
problematic. VM is a wonderful thing, but it can be easily abused in
any situation where the size of "objects" often exceeds the size of
physical RAM. this is true for a lot of soundfiles.
--p
This archive was generated by hypermail 2b28 : Wed Aug 01 2001 - 16:08:33 EEST