Re: [fluid-dev] A question of memory

[Paul Millar]

Hi Dave,

Thanks for the info, some comments below...

On Tuesday 21 November 2006 20:02, Dave Serls wrote:
> On Tue, 21 Nov 2006 19:45:57 +0000
> Paul Millar <address@hidden> wrote:
> > [...] I'm loading a 30 MB SoundFont file, [...]
>   When mlock=1 is enabled for realtime kernels,

Just to check, this is the mlock option for the realtime LSM kernel module, 
right?  I hadn't heard of the module before... (must have be living under a 
rock or somethin').  So, as described here:
  http://lwn.net/Articles/106010/

The mlock man page says that, since Linux 2.6.9, unprivileged processes may 
lock memory (upto RLIMIT_MEMLOCK).  On my Debian box, I have an unlimited  
maximum locked memory size.  I've not fiddled with it, so I'd guess this is 
common.

>  that memory is pinned 
> (page-fixed) and very large soundfonts combined with multiple engines (via
> qsynth) can deplete real memory into the OOM-killer range.

Sure enough, running:
        strace -e mlock,munlock,munlockall,munmap ./simple-fluidsynth-test 
~/path/to/SF
shows a call as mlock(0xa5ea2008, 30316800).  The SoundFont file (on disk) is 
a little bigger (at 30522278 bytes).

There doesn't seem to be any effort to free this memory.  I tried added an 
explicit call to fluid_synth_sfunload(), but no effect.  Hmmm...

>   I'm running a poor patch to qsynth to re-use soundfonts across synth
> engines. It's not correct, but it prevents disaster.

Sure, but in my case I'm fluid_delete_*()-ing everything: audio driver, synth 
and settings.

This can happen when my program (MonAMI) is shutting down (so, no great 
problem) or when someone has signalled a sighup, causing it to reload the 
(MonAMI's) configuration.  Leaking a few megabytes of locked memory isn't so 
good :-(

Cheers,

Paul.

pgpUYuhYl0A1J.pgp
Description: PGP signature