Jenny Zhao (zhz++at++dandan.engr.sgi.com)
Sat, 21 Nov 1998 04:26:33 -0800
The DBASE paging problem you ran into is probably caused
by a bug when deleting ASD nodes. ASD node deletion
didn't get worked on enough in 2.2 since we concentrated
our efforts on large
paging ASDs so paging can be handled by ASD internally,
just like MPclipmap nodes. We are looking at the bug now.
However I don't think it is the same as the
memory problem that Mark saw. Mark's problem
might be caused by memory fragmentation.
Mark, how do you generate the paging units? each time
are you paging in same sized database cells or
quite different sized database cells?
if each time you can paging in the same sized memory,
you can call
amallopt(M_FREEHD, 1, pfGetSharedArena())
to put any freed memory in the front of
the free list so it will be allocated again when
you page in the new cell.
however, if the memory you page in varies in
size quite a bit, the memory will fragment pretty badly, I think.
There are some ways to solve the problem.
For example, ASD paging scheme models the large
terrain into multi-resolution uniformed tiles.
Every time a tile is read in, it replaces an
old tile in memory. There is no memory fragmentation
since the memory is divided into equal sized
chunks.
you can also make sure your database is divided up
into exactly the same sized pfGroup or pfLOD nodes.
use the amallopt option and hope the system will do
the right thing.
you can even go further, like ASD, to replace
the memory yourself instead of using Load and AsyncDelete.
However, you have to make sure the paging scheduler
will handle the timing correctly.
Subject: Re: database paging memory leak
In-reply-to: "EXT AVS; info-performer Mailing List" <info-performer++at++sgi.com>
<"info-performer Nov 19 1998"++at++turner.air.saab.se> (Nov 20, 2:00am)
To: info-performer++at++sgi.com
Cc: mark.wear++at++lmco.com
Message-id: <MAA07125++at++saab.se>
MIME-version: 1.0
X-Mailer: Z-Mail (3.2.1 10apr95)
Content-type: text/plain; charset=us-ascii
References: <199811201000.CAA18416++at++holodeck.engr.sgi.com>
Hi Mark!
I'm hardly an expert in this area, but I have used the method myself and
experienced similar problems. I tried to page in patches of an ASD terrain
in the DBASE process by using exactly the same method as you are. My program
crashed when I used pfAsyncDelete(). After some support from SGI I succeeded
by using the following multiprocess mode:
pfMultiprocess(PFMP_APPCULL_DRAW | PFMP_FORK_DBASE | PFMP_FORK_COMPUTE)
The Compute process is used by the ASD evaluation, and can be excluded in
your case. I'm sure you already have forked the DBASE, but the trick is to
avoid forking the CULL process. Of course, this shouldn't be necessary. It's
probably a bug, but this solves the problem temporarily. Maybe this is the
source of your problem too, try it out.
Best wishes,
Andreas Ekstrand
> From: "Wear, Mark" <mark.wear++at++lmco.com>
> Date: Thu, 19 Nov 1998 10:15:01 -0700
> Subject: database paging memory leak
>
> Hello,
>
> I am using the performer DBASE process to page-in manageable chunks of
> extremely large (country size) databases. During each build, I construct the
> needed piece of scene graph in the asynchronous DBASE process within a
> pfBuffer. After construction of my new scene, I register commands to swap
> the old group (the group currently being drawn) with the new group using
> pfBufferRemoveChild and pfBufferAddChild. After pfBufferRemoveChild, I then
> request the asynchronous deletion of the old scene graph group node using
> pfAsyncDelete(). I then merge the pfBuffer. I directly modeled this method
> after an example given in the Iris Performer Student Handbook.
>
> I am experiencing a memory leak which appears to be proportional to the
> number of polygons created during a build. I have tracked this leak to the
> deletion of the old portion of scene graph. I believe this to be the case
> because if I build my new scene as usual, but never swap the new and old
> groups, and thus never call pfAsyncDelete(), the memory leak disappears.
>
> Is the memory associated with a pfBuffer freed appropriately after a merge?
> Could the request for asynchronous deletion of the old group be getting lost
> on occasion? Could my problem be caused by fragmentation of the shared
> memory arena? Is there a better way to accomplish the paging of a large
> database?
>
> Any ideas or suggestions?
>
Jenny Zhao zhz++at++engr.sgi.com 650 933-5091
Silicon Graphics - Manager of IRIS Performer
This archive was generated by hypermail 2.0b2 on Sat Nov 21 1998 - 04:26:36 PST