Conference turris::fortran

>>My post explained our current hack to get this info, and yes I REALLY need
>>to know, our target machine has very limited memory.

  I'm puzzled by the mention of "very limited memory". In this context,
  people usually mean REAL memory.

  But if allocations are done on the heap, then wouldn't you be limited by
  the size of virtual memory, not real memory (ignoring that once you
  exceeded real memory, you might page like crazy).

  So what the program measures is the amount of dynamic virtual memory
  available, which is limited by a number of system related things:
  amount of page/swap file, shell imposed limits on "datasize",
  kernel parameter max. virtual address space, lazy or eager swap file
  policy, etc. etc. But real memory isn't one of them.

  Almost always, when a process runs out of dynamic memory, it is due to
  the shell imposed limit on "datasize" being too low. Next in line is
  not enough page/swap file. (One could look at the output of
  /usr/sbin/swapon -s to see the total available swap/page file as the
  process runs).

  -- John Faricelli

Date:	 4-JUN-1997 10:58:06.09
From:	SMTP%"[email protected]"
Subj:	Re: On memory allocation...

Hi Steve

On Wed, 4 Jun 1997, Steve Lionel wrote:
> [this is from another engineer...]

Understood.  May I add that a DUnix OS specific solution is fine, I don't
expect anything remotely portable.  I tried playing around with getrusage
calls, but some of the results didn't appear to make much sense (to me at
least!)  

> >> My post explained our current hack to get this info, and yes I REALLY need
> >> to know, our target machine has very limited memory.
> 
>   I'm puzzled by the mention of "very limited memory". In this context,
>   people usually mean REAL memory.

very limited memory == 64 MB real memory on a node of a T3D (which has no
virtaul memory at all!) I have a code with loads of data sets, some of which
will run on a node of a T3D, some will not.  I'm trying to squeeze things so
that the code fits on a node for as many cases as possible, with dynamic
allocation / deallocation, dumping/reading some things to/from disk, etc.  I
can obviously use size to get the static size of my process at the outset,
but I need to track how much dynamic memory I'm using as the process
progresses to find out the high-water mark for the whole code.  Any
tool/technique which can accomplish this solves my problem.  Unfortunately
the code contains hundreds (if not thousands) of calls to F90 allocate /
deallocate, so tracking from within the code seems impractical. Something
that tracks F90 allocate / deallocate calls wpould probably give me all the
info I need.  Is there an ATOM tool to do this?

>   But if allocations are done on the heap, then wouldn't you be limited by
>   the size of virtual memory, not real memory (ignoring that once you
>   exceeded real memory, you might page like crazy).

Yes.  I should explained this more fully .....

>   So what the program measures is the amount of dynamic virtual memory
>   available, which is limited by a number of system related things:
>   amount of page/swap file, shell imposed limits on "datasize",
>   kernel parameter max. virtual address space, lazy or eager swap file
>   policy, etc. etc. But real memory isn't one of them.

My process must have a virtual memory size, on the T3D this will be the real
memory size (a pretty crude approximation I know).  And on a T3D node (or
T3E for that matter) there is only one use process plus a microkernel, so no
resource sharing at all.  I could of course do all my development on the T3D
itself, but then I must contend with long turnaround times, slow compilers,
limited access, etc.  I prefer the DEC compilers / tools / environemt
anuway, and the 8400 I use is lightning quick on this code.

>   Almost always, when a process runs out of dynamic memory, it is due to
>   the shell imposed limit on "datasize" being too low. Next in line is
>   not enough page/swap file. (One could look at the output of
>   /usr/sbin/swapon -s to see the total available swap/page file as the
>   process runs).

The system I use for development is a 6 processor DEC 8400, with 2GB
physical memory.  limits are :

% limit
cputime         30:00
filesize        unlimited
datasize        2097152 kbytes
stacksize       32768 kbytes
coredumpsize    0 kbytes
memoryuse       1048576 kbytes
descriptors     4096 
% limit -h
cputime         30:00
filesize        unlimited
datasize        2097152 kbytes
stacksize       32768 kbytes
coredumpsize    unlimited
memoryuse       1048576 kbytes
descriptors     4096 

% /usr/sbin/swapon -s
Swap partition /dev/rz12b (default swap):
    Allocated space:        12800 pages (100MB)
    In-use space:            8046 pages ( 62%)
    Free space:              4754 pages ( 37%)
Swap partition /dev/rz24b:
    Allocated space:       261877 pages (2045MB)
    In-use space:            7960 pages (  3%)
    Free space:            253917 pages ( 96%)
Swap partition /dev/rz32b:
    Allocated space:       261877 pages (2045MB)
    In-use space:            7971 pages (  3%)
    Free space:            253906 pages ( 96%)
Swap partition /dev/rz40b:
    Allocated space:       261877 pages (2045MB)
    In-use space:            7964 pages (  3%)
    Free space:            253913 pages ( 96%)
Swap partition /dev/rz49b:
    Allocated space:       261877 pages (2045MB)
    In-use space:            7971 pages (  3%)
    Free space:            253906 pages ( 96%)
Swap partition /dev/rz57b:
    Allocated space:       261877 pages (2045MB)
    In-use space:            8006 pages (  3%)
    Free space:            253871 pages ( 96%)
Total swap allocation:
    Allocated space:      1322185 pages (10329MB)
    Reserved space:        133735 pages ( 10%)
    In-use space:           47918 pages (  3%)
    Available space:      1188450 pages ( 89%)

I hope that supplies some helpful info.

Thanks,
Kevin
--
Kevin Maguire         __    __    __    __           Daresbury Laboratory
[email protected]   /  \  /  \  /  \  /  \      Warrington, Cheshire, UK
____________________/  __\/  __\/  __\/  __\_____________________________
___________________/  /__/  /__/  /__/  /________________________________
                   | / \   / \   / \   / \  \____   voice: (01925) 603221
                   |/   \_/   \_/   \_/   \    o \    FAX: (01925) 603634
                                           \_____/--<                    

    Hmmm, I think I can tell you how to find the total size of the
    current process, but I'm not sure how to go about finding the 
    amount left to allocate.  Oops, wait, just figured that out.
    It involves a few C calls, or you can write a C subroutine
    and just call that from the Fortran routine.  The C calls are
    system calls and involve C structures that are returned via
    pointers so it might be easiest to go the C subroutine called
    from fortran main program route.  The system calls involved are
    getrlimit and one of the procfs subroutines.  Getrlimit is
    in the manpages (which is how I found it after I started this 
    reply) and gives you the current and maximum limits available
    to the process.  I take this to mean that it gives you the maximum
    number of bytes you can grab in total.  The proc call is
    an ioctl call in which you request PIOCPSINFO, and among the 
    data returned are pr_size, which gives the total size of the 
    process in PAGES, and pr_rssize, the resident set size, also
    in pages.  So you have to convert that by multiplying the returned
    value by whatever the page size is, to get a comparible figure.
    In order to do the proc ioctl, you have to open up the process in 
    /proc, and then request the info via the ioctl.  Here's a test
    program I wrote up in C to do this.  It should be easily modifiable
    to do what they want:
    
    
    #include <malloc.h>
    #include <unistd.h>
    #include <stdlib.h>
    #include <stdio.h>
    #include <fcntl.h>
    #include <errno.h>
    #include <sys/stat.h>
    #include <sys/types.h>
    #include <sys/resource.h>
    #include <sys/signal.h>
    #include <sys/fault.h>
    #include <sys/syscall.h>
    #include <sys/procfs.h>
    #include <sys/ioctl.h>
    
    int main (int argc, char **argv)
    {
       char fileName[12];
       int fd;
       int i;
       prpsinfo_t pInfo;
       void *buff;
       struct rlimit *rlp;
    
       sprintf (fileName, "/proc/%d", getpid ());
       fprintf (stdout, "Opening %s\n", fileName);
       fd = open (fileName, O_RDWR);
       if (!fd)
       {
          fprintf (stderr, "Failed to open %s\n", fileName);
          return (-1);
       }
    
       rlp = (struct rlimit *) malloc (sizeof(struct rlimit));
       getrlimit(RLIMIT_AS, rlp);
       printf("Current limit %ld, maximum limit %ld\n", rlp->rlim_cur,
    	  rlp->rlim_max);
    
       for (i = 0; i < 10; i++)
       {
          if (ioctl (fd, PIOCPSINFO, &pInfo) == -1)
          {
             fprintf (stderr, "Failed ioctl errno: %d\n", errno);
             return (-1);
          }
          fprintf (stdout, "RSS: %d\n", pInfo.pr_rssize);
          fprintf (stdout, "Size: %d\n", pInfo.pr_size);
          buff = malloc (50000);
       }
    
       close (fd);
       return (0);
    }
    
    
    Here's the output (Note that the size is the same in a few subsequent 
    runs through the loop.  I think the system grabbed enough so that
    the subsequent alloc, while increasing the resident set size,
    did not cause the overall size of the process to be increased.)
    
    petert@dippikill 71> rss
    Opening /proc/1245
    Current limit 1073741824, maximum limit 1073741824
    RSS: 15
    Size: 199
    RSS: 16
    Size: 206
    RSS: 17
    Size: 206
    RSS: 19
    Size: 213
    RSS: 21
    Size: 220
    RSS: 23
    Size: 227
    RSS: 25
    Size: 234
    RSS: 27
    Size: 241
    RSS: 28
    Size: 248
    RSS: 29
    Size: 248
    
    
    PeterT