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?
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?
In previous messages the question seems highly specialized and I
am not an expert in this matter. For example, in a message
> Subject: Re: rdsinit death
> Date: Mon, 31 Jan 2000 15:27:32 -0500
it was written:
> It could be that there is not a big enough chunk of memory available in
> the memory map around the address that we try to mmap the data segment.
> Try to figure out where shared libraries and such are mapped. I believe
> we use 0x20000000 as the base address for RVM data, and it sounds like
> something else could be in your memory map about 150MB above this point
> (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.
In a later message there are the comments:
> > Does this mean I have to pick a custom range for my RVM Data mapping, and
> > if so, how should I go about this? The same way that was mentioned
> > a week or so ago when discussing setting up RVM for a 42 Gig server,
> > with a start address of 0x41000000 (checking, of course that this is free
> > by checking /proc/{pid}/maps)?
> Yeah, 0x50000000 could be a good choice, is also used by NetBSD 1.3/14
> and FreeBSD. RVM stores the startaddress in the header of the RVM data
> file during initialization and will always remap to that address.
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. I have installed several dozen public
domain packages and of all of them "coda" has given me the most problems.
Alan Scheinine Email: [EMAIL PROTECTED]
