Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!hsdndev!think.com!samsung!cs.utexas.edu!execu!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.unix.aix
Subject: Re: Memory boards and data space
Message-ID: <19042@rpp386.cactus.org>
Date: 9 Feb 91 15:11:29 GMT
References: <2217@njitgw.njit.edu> <5141@awdprime.UUCP>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 34
X-Clever-Slogan: Recycle or Die.

[ 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.