Re: Comm buffer leak for upstream-going messages?

Hi Mike;

> I don't know the quadrics code very well, but my guess is that large 
> userspace messages, like textures and readpixels calls, are not getting 
> freed correctly.  The general problem with the current network layer is 
> that we need to use fixed size buffers for general traffic so we can 
> pack things on the wire correctly.  However, when you have big data 
> sends, the highspeed layers break the large message into many smaller 
> messages.  If those aren't getting freed correctly, then you will run 
> out of memory on the board.  Are you running out of memory on the send 
> or recv side?

I'm running out of memory on the application (client) side.  I have 
instrumented things just as you describe, and I see the crNetFrees happening 
on the server side but not on the client side.  For example, when the app 
calls glGetError() a Quadrics message is sent downstream (and properly freed 
at the server end), and a reply message is generated at the server and 
received at the client end.  However, the buffer that comes back up with the 
reply message is never freed.

-Joel

> 
> The only real way to track this down is to place crDebug's throughout 
> the teac code and track every message moving through the layer to see 
> why messages sent or received are not getting freed.  But, I would first 
> look at the large send code.
> 
> We will hopefully have an MPI-2 network layer soon for Chromium that 
> might solve these issues for the most part assuming your hardware is 
> supported by LAM MPI-2.  The good folks at SGI have done the initial 
> work and I'm waiting for the code to be patched to run with the current 
> tree.  If there is enough interest, I might be able to get SGI to dump 
> the code into the tree and then we can all bang it into shape. 
> 
> The other option is to move all of the network layers over to a socket 
> version (SDP, Sockets-GM, etc).  SDP with Infiniband works great.  ;-)  
> Even better with AIO.
> 
> -Mike
> 
> Joel Welling wrote:
> 
> >Hi folks;
> >  I'm trying to integrate ParaView and Chromium at the moment, and it's going 
> >very well when I use tcpip networking in Chromium.  When I substitute Quadrics 
> >Teac networking it runs for a while and then fails because the Quadrics card 
> >runs out of on-board memory, which in turn seems to happen because 
> >upstream-going messages (like the results of glGet...() and glReadPixels()) 
> >are not being reclaimed.  Can anyone tell me where this is supposed to happen? 
> > I've looked at the invocations of crNetFree(), and none seem to be in the 
> >obvious places to accomplish this.
> >
> >Thanks,
> >-Joel
> > [email protected]
> >
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by:
> >Sybase ASE Linux Express Edition - download now for FREE
> >LinuxWorld Reader's Choice Award Winner for best database on Linux.
> >http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> >_______________________________________________
> >Chromium-dev mailing list
> >[email protected]
> >https://lists.sourceforge.net/lists/listinfo/chromium-dev
> >  
> >




-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click