(Illustration by Gaich Muramatsu)
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. JanReceived on 2002-06-10 11:37:02