On Thu, Mar 30, 2000 at 10:22:41AM +0200, Alan Scheinine wrote:
> What memory is available for memory mapped files?
> Is it:
>    (1) All of the physical memory and swap space?
>    (2) Just the physical memory?
>    (3) The amount of space [physical [plus swap?]] not
>        being used by other processes?

Normally the answer would be the amount of space not used by other
processes (physical + swap), as long your process does not exceed 4GB on
a 32-bit architecture.

However, linux 2.0/2.2 only allow 2GB of addressable space per process.
And large parts of memory is already used by code, data, stack, shared
libraries and possibly mmapped files that are used by those libraries
(/etc/hosts, /etc/passwd come to mind in some cases). Where things are
loaded depends a lot on the system environment, a.out or elf binary
format, static or shared libraries, whether we can `overcommit' memory
allocations, the ulimit settings.

This all gets complicated a little bit with miscelaneous OS bugs,
library bugs and other niceties of life. Luckily there are also 64-bit
processors which suddenly have all the space needed, too bad Coda isn't
64-bit clean yet.

> We run numerical simulations that use nearly all of the physical
> memory -- and then some.  Does this mean the memory available to
> coda is thus limited?

Yes and no, physical memory is almost never a limitation on unix
machines, in general the physical+swap is the upper bound of the size
which all processes can occupy, with various exceptions ofcourse.
However we need a single contiguous gap in which to fit the RVM data
segment, and the `other crud' in a process's (virtual) memory space
makes it harder to find this. Especially considering that there is no
standard way of discovering what is in use and what is not.

>    > (around 0x25000000). On linux, /proc/<pid>/maps should give all the info
>    > about which addresses are already used up.
> 
> But there are about 50 files /proc/<pid>/maps.

That's probably why it is very difficult to figure out the appropriate
spot to fit in the RVM data segment. Especially when different
architectures and operating systems tend to map things slightly
differently.
Files? /proc/<pid>/maps is not a directory. On a 2.2/2.3 system it
should even annotate the lines with the name of the file that is mapped.

On linux in general the virtual address space of a codaserver process is
as follows:

08000000->	   process code and data (data grows up due to malloc() calls)
15000000->	   LWP thread stacks (more threads == more stacks).
20000000-	   RVM data mapping (fixed size).
40000000->	   Shared libraries and misc. memory mappings.
        <-c0000000 Main process stack.
(-> = growing upwards, <- = growing downwards)

> I realize that the WWW site of coda emphasizes that the software is
> at beta level.  Nonetheless, asking users to study the situation as
> described above does not seem to be a reasonable direction for the
> development of the software.

Maybe, maybe not. I never saw any response whether the 0x50000000
suggestion was any good, so why change the defaults?

>                               I have installed several dozen public
> domain packages and of all of them "coda" has given me the most problems.

Coda has a lot of nice features, in fact is probably has too many nice
features. In addition development started around the time that there was
no `standard' threading/rpc/persistent VM available. It tries to do
everything by itself, I sometimes wonder why nobody bothered to
integrate Xemacs into Coda as well.

The sum of this is, Coda is a very complex system, probably more complex
than most (or all) of the several dozen packages you installed. We are
trying to do our best, but there is a lot of work to be done. Would you
rather have us not release anything then?

Jan