[comp.unix.aix] Memory boards and data space

sampath@mars.njit.edu (sampath s k) (02/03/91)

   Hi,

       Program:
       --------
       I have a program that builds a huge graph. During the 
       graph building phase a lot heap space (malloc()) is
       used and a lot of stack space is used during the graph
       traversal as it is extremely recursive.

       Environment:
       --------
       The above mentioned program is tested on an IBM RS6000 
       (model 530 AIX 3.1) with ~ 80 MB of real memory and 256 MB 
       of paging space.
       
       Problem:
       --------
       The program is abnormally terminated during the graph traversal
       phase for lack of paging space. Increasing the paging space beyond
       256 MB doesn't seem to help. 

       Question:
       ---------
       Is it possible possible for the above mentioned program to work
       if I thrown in extra memory boards? Do extra memory boards
       increase the data (heap+stack) space? Please shed some
       light on this issue. Thanks for your time.

                     -- sampath         sampath@mars.njit.edu  

frank@leopard.austin.ibm.com (02/06/91)

>        The program is abnormally terminated during the graph traversal
>        phase for lack of paging space. Increasing the paging space beyond
>        256 MB doesn't seem to help.

Are you sure that it is being terminated for 'paging space' and not because
you are out of heap?  I forget what the default heap is, but look into the
ulimit command (for ksh or sh).  To increase your limit, have the administrator
use smit to change your user options.

>        ---------
>        Is it possible possible for the above mentioned program to work
>        if I thrown in extra memory boards? Do extra memory boards
>        increase the data (heap+stack) space? Please shed some
>        light on this issue. Thanks for your time.

No, extra real memory does not effect your data, heap or stack space.  Also,
there is a hard limit of 256 MB per segment.  This means that unless you do
some programming tricks (which I don't know the specifics of) you are stuck
at this limit.

- Frank Feuerbacher


Disclaimer: I don't speak for my employer and they don't speak for me.

jfh@rpp386.cactus.org (John F Haugh II) (02/09/91)

[ Frank mistakenly redirected this to comp.unix.wizards.  Since it only
  applies to AIX v3 I am sending it back to comp.unix.aix ]

In article <5141@awdprime.UUCP> ...@cs.utexas.edu:ibmaus!auschs!leopard.austin.ibm.com!frank writes:
>>        The program is abnormally terminated during the graph traversal
>>        phase for lack of paging space. Increasing the paging space beyond
>>        256 MB doesn't seem to help.
>
>Are you sure that it is being terminated for 'paging space' and not because
>you are out of heap?  I forget what the default heap is, but look into the
>ulimit command (for ksh or sh).  To increase your limit, have the administrator
>use smit to change your user options.

Better still, vi the file /etc/security/users and look at the values in
the "default" stanza.  Change them there so that everyone can benefit.
But be careful that you don't change to too big or no one may be able to
log in any longer ...

>No, extra real memory does not effect your data, heap or stack space.  Also,
>there is a hard limit of 256 MB per segment.  This means that unless you do
>some programming tricks (which I don't know the specifics of) you are stuck
>at this limit.

Memory map a file or create a shared data segment.  Either of these two
techniques will create room for an additional 256MB of address space.
Regrettably malloc() doesn't know about this trick (nor should it, if you
consider the behavior of mapped files and shared segments with respect
to fork and exec and how your data segment behaves with respect to both
of those system calls ...).
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org
"I've never written a device driver, but I have written a device driver manual"
                -- Robert Hartman, IDE Corp.