On Thu, Jun 06, 2002 at 07:26:33PM +0100, Chris Shiels wrote:
> Firstly, thank-you for the very prompt reply to the email - much
> appreciated.
This reply is a bit less prompt. My parents are in town, so I'm not at
CMU all the time ;)
> When we did our install we were lazy and went with the 5.3.19 RPM's -
> will it be ok to just build and then deploy the /usr/sbin/codasrv
> binary and run this with the files from the 5.3.19 RPM's or are there
> additional files or issues that I need to consider?
That should work fine. I typically try to keep the servers compatible
as it simplifies life with testing. Setting up a new server everytime I
rebuild would become annoying at best. Clients are more likely to
require a reinitialization after upgrading as everything should normally
be on the servers and can be refetched.
> Also, a few things I'm not clear on:
>
> We're currently running 30M(log)/500M(data) and I've found that I
> can't go to 30M(log)/1G(data), are there any other RVM data sizes that
> are available after the 500M one? If so then how are the sizes
> calculated?
You can get pretty much any size you want. The RVM data is split between
two segments, a static area and a dynamic heap. The static area always
contains about 1MB, whatever the size of RVM. Then there is a little bit
of fixed overhead, a description of the size and where to load these 2
segments and the RVM header, about 3-4 pages (about 16KB) the rest is
used for the dynamic heap.
So all the parameters,
rdsinit -f totalsize address heapsize staticsize nlists chunksize
totalsize - is how much on-disk data RVM should use.
address - is where RVM data is mapped into memory. Lower addresses
allow for a larger total size, but you might collide
with shared libraries. On Linux you can check with cat
/proc/<pid>/maps where the various shared libraries are
loaded. The binary itself is loaded at 0x08000000, and
shared libraries start around 0x40000000. The stack
growns down from 0xc0000000, and you definitely don't
want RVM to clobber the stack (or the other way
around). A static binary might be bigger, but doesn't
need the shared libraries, so the start address can be
lowered significantly.
heapsize - ~= totalsize - ( staticsize (1MB) + overhead (16KB) )
rounded to a multiple of 4KB
staticsize - 0x100000 (1MB)
nlists - the allocator is using this many buckets to quickly
find free small memory chunks. first bucket contains
chunksize, the second 2*chunksize, 3*chunksize, etc.
someone once set this to 80, and that's the way it has
been. This should make the largest allocation list
about 2560 bytes.
chunksize - smallest allocatable piece of memory, must at least be
able to fit 2 pointers and 2 longs. So you'd need at
least 16 bytes, but 32 is a safe and good choice.
Jan
