Re: [Om-synth] om and lash memory usage

[Dave Robillard]

On Tue, 2005-25-10 at 11:21 +1000, Dave Robillard wrote:
> On Mon, 2005-24-10 at 08:52 +0200, Antonio wrote:
> > Hi,
> > 
> > I've note that simply launching lashd, lash_panel, om and om_gtk with
> > an empty patch eats lots of memory. Here is top's output:
> > 
> >   PID %CPU S  NI COMMAND                 USER      VIRT  RES  SHR SWAP %MEM 
> >  PR
> >   7960  0.0 S   0 om                      anto     73368  71m 6540    8 
> > 28.6  15
> >   7949  0.0 S   0 lashd                   anto     46424  45m 4944    0 
> > 18.1  16
> >   7824  1.4 S   0 jackd                   anto     35696  34m 2524   16 
> > 13.9  18
> >   7823  0.0 S   0 qjackctl                anto     27992  27m  17m    0 
> > 10.9  15
> >   7969  0.0 S   0 om_gtk                  anto     58024  14m  10m  42m  
> > 5.8  15
> > 
> > If I launch om without lashd the memory usage decreases of ~ 20MB. I
> > have 256MB of ram (yes I know they aren't too much) and the swap
> > become heavily used even on a simple session.
> > 
> > Is this the average memory usage?
> 
> Om has memory usage issues I'm trying to get to the bottom of.

Got to the bottom of them. :)

Turns out it's the fault of mlockall().  Om in CVS now consumes 2.5MB on
startup instead of 38MB as before (!!).

Then you start the Gtk client, which launched the jack driver, which
calls mlockall() and bring all the useless garbage back into memory :(.
I sent a mail to the Jack list about this problem, I don't think this is
acceptable behaviour whatsoever.  I'm on a 512MB system and I can just
barely squeeze everything into RAM I need for a session as well.

Anyway, I did manage to trim the fat quite a bit by eliminating a thread
and shrinking the stack size of any threads I could.  There should be a
drop of roughly 20MB consumption, hope that makes the situation a little
more tolerable for the time being at least.

It's very possible shrinking those stacks will cause things to die
horribly, especially on different architechtures. If anyone tries it out
on an AMD64, please let me know how it goes.

Also, did a data structure swap in the audio thread that should cut down
the processing overhead of DSP processing (nothing catastrophic, but an
improvement nonetheless) and trim a teeny bit of memory as well.

Cheers,

-DR-