Jean-Claude Bachmann (jean-claude.bachmann++at++artemedia.de)
Tue, 23 Dec 1997 12:00:51 +0100
amallopt(M_MXCHK, 1000000, pfGetSharedArena());
amallopt(M_FREEHD, 1, pfGetSharedArena());
amallopt(M_MXFAST, 64, pfGetSharedArena());
amallopt(M_GRAIN, 64, pfGetSharedArena());
Another 15h run then showed 70MB less memory usage, but that's still
an 80MB plus. Using gmemusage, I found out that all of the bloat
happens in the draw process, which I took as an indication of the
fragmentation phenomenon.
What I don't understand though: After a fresh start the draw process
takes up ~20MB of memory, most of it in swap space (where the shared
arena is located). After running for a while, it gobbles up ~108MB, of
which only 28MB are in swap, and 80MB on the heap! Can this still be
due to memory fragmentation? Does the draw callback allocate memory
on the heap or in the shared arena?
I then traced memory usage with amallinfo(), but the output left me
puzzled. It shows (after loading the scene data) an almost constant
value uordblks, that only grows 1MB over 4 hours. usmblks didn't grow at
all.
I tried mallinfo(), too, but that as well shows no growth in
mem usage after the initial startup.
Oh, the system is an Onyx2/IR2 with IRIX 6.4, Performer2.1, 1.5GB RAM.
Merry Christmas to all of you
J.C. and Kolja Kaehler
--******************************************************************** * Artemedia GmbH | Tel.: +49 [0]30 25443 - 0 * * Jean-Claude Bachmann | Tel.: +49 0172 - 219 13 76 * * Hardenbergplatz 2 | Fax.: +49 [0]30 25443 - 400 * * D-10623 Berlin | email: jean-claude.bachmann++at++artemedia.de * * Germany | Web Page http://www.artemedia.de * ********************************************************************
Our application (architectural walk/flythrough) exposes memory bloat
when being run over a long time. After a 15h test run (using gmemusage) it grew from
overall 218MB to 378MB. I browsed the discussions about memory
fragmentation in the mailing list archives and put the following
statements into the code:amallopt(M_MXCHK, 1000000, pfGetSharedArena());
amallopt(M_FREEHD, 1, pfGetSharedArena());
amallopt(M_MXFAST, 64, pfGetSharedArena());
amallopt(M_GRAIN, 64, pfGetSharedArena());Another 15h run then showed 70MB less memory usage, but that's still
an 80MB plus. Using gmemusage, I found out that all of the bloat
happens in the draw process, which I took as an indication of the
fragmentation phenomenon.What I don't understand though: After a fresh start the draw process
takes up ~20MB of memory, most of it in swap space (where the shared
arena is located). After running for a while, it gobbles up ~108MB, of
which only 28MB are in swap, and 80MB on the heap! Can this still be
due to memory fragmentation? Does the draw callback allocate memory
on the heap or in the shared arena?I then traced memory usage with amallinfo(), but the output left me
puzzled. It shows (after loading the scene data) an almost constant
value uordblks, that only grows 1MB over 4 hours. usmblks didn't grow at
all.I tried mallinfo(), too, but that as well shows no growth in
mem usage after the initial startup.Oh, the system is an Onyx2/IR2 with IRIX 6.4, Performer2.1, 1.5GB RAM.
Merry Christmas to all of you
J.C. and Kolja Kaehler
-- ******************************************************************** * Artemedia GmbH | Tel.: +49 [0]30 25443 - 0 * * Jean-Claude Bachmann | Tel.: +49 0172 - 219 13 76 * * Hardenbergplatz 2 | Fax.: +49 [0]30 25443 - 400 * * D-10623 Berlin | email: jean-claude.bachmann++at++artemedia.de * * Germany | Web Page http://www.artemedia.de * ********************************************************************======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer++at++sgi.com Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:56:28 PDT