[Mpi-22] Memory footprint concern

Richard Treumann treumann at [hidden]
Thu May 8 16:22:39 CDT 2008

Can somebody help me understand this "smaller memory footprint" issue that
is part f the subsetting goal better. What systems does it affect? What
does "memory footprint" really mean? In the 64 bit address space, virtual
address range is not a problem.

On systems I am most familiar with (AIX and I have been told Linux too), if
you have a library that contains 1000 subroutines and you run a program
than only calls 6 then only the pages that are touched by code for those 6
functions must get placed in real memory. The rest of the object code stays
on disk. Program and library text is demand paged. The loading is on page
boundries, not subroutine boundries.

With a shared library, if I run a program on a node and touch 6 subroutines
and you run a different program that touches those 6 and 10 more then code
for all 16 subroutines may be kept in memory but the rest of the library
will stay on disk. You and I will share the object code for the 6
subroutines we are both calling.

Someone who wanted to make a libmpi that has MPI-1sided or MPI-IO well
isolated in the library structure so simple MPI jobs would not force this
extra code into memory could do that today. The user does not need to
promise not to call MPI-IO subroutines for them not to to take real memory.
The "subsets" would need to be devised by the MPI implementor but would be
transparent to the MPI user and not dictated by the standard. The "subsets"
the user did not call would remain paged out.

Perhaps all static data defined by the library will come into real memory
for each process but is there much reduction from being able to somehow not
bring in the static data MPI-IO would require because somebody had promised
not to use it?


Dick Treumann  -  MPI Team/TCEM
IBM Systems & Technology Group
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846         Fax (845) 433-8363

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-22/attachments/20080508/64ff2883/attachment.html>

More information about the Mpi-22 mailing list