[PD-dev] memory locking policy

[Tom Schouten]

On Wed, Oct 20, 2004 at 03:39:48PM +0200, Tim Blechmann wrote:
> > > it seems this indeed can only be solved by allocating everything
> > > in advance.. so what you suggest might be a good idea.
> > > 
> > > maybe a special-purpose malloc would do the trick?
> > 
> > i mean, one that does not free the pages to the kernel.
> > like pdp works :)
> 
> that might be a solution ... or not allocating everything in advance,
> but using a helper thread that keeps a few mb allocated ...
> for the threaded soundfiler a few mb wouldn't be enough, since it works
> on a second array ...
> 
> the easy approach would be to mlock the parts of memory after allocating
> ... the difficult approach to write a rt-save malloc ...
>

always go for the difficult solution Paul Graham would say. :)
 
> from what i understand the memory allocation in pdp, you keep track of
> the already allocated memory ... i'm not sure, if this would solve our
> problem ... 

no. in pdp it is simple, because all the packets (or most of them)
have the same size. there is a reuse queue for each packet type.
so this does not work if you use a lot of types.

> of course there are many allocations of the same size, but
> for other, especially big audio arrays, it will be very unlikely to
> reuse the memory ... and that's exactly the point, where the threaded
> soundfiler had it's problems ...
> 

indeed.
it's a problem that needs to be tackled at the root: malloc

real time memory allocation is pretty damn difficult to do..
hence real time GC is something most people avoid.

all the other things are workarounds for special cases.
some might work now, but will probably bite back later.