(Illustration by Gaich Muramatsu)
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? JanReceived on 2000-03-30 15:54:03