badri@ur-valhalla.UUCP (02/14/87)
I posted this question sometime back but did not get a single reply, so
either something got screwed up or this newsgroup is read by a bunch
of heartless twerps!
We run BSD 4.2 on a VAX 11/750 with 2M core and 16M swap space.
We have a some software written in fortran77, that has hardwired
array sizes in it. We do not want to rewrite the code for dynamic
memory management right now, though it will be done eventually. The
problem is that when the array sizes exceed some value, we get a
message "Not enough core". By playing around with array sizes, I have
the following details from /bin/size:
Wire1 (Works)
text data bss dec hex
384000 66560 6071296 6521856 638400
Wire2 (Does not work)
text data bss dec hex
384000 66560 6988076 7438636 71812c
By putting debug messages in the kernel (auuugh!), I have narrowed the
problem down to the following:
ctod(ds) = 12906 exceeds maxdmap = 12256 in /sys/machine/vm_machdep.c
Does someone know if there are kernel parameters that can
be tweaked to get around this problem? I know that I am not directly
exceeding the hardlimits MAXTSIZE, MAXDSIZE or MAXSSIZE.
If there are any, I would like to know the consequent side effects of
changing them.
Thank you,
Badri Lokanathan
--
"We will fight for the right to be free {) ur-valhalla!badri@rochester.arpa
We will build our own society //\\ {ames,caip,cmcl2,columbia,cornell,
And we will sing, we will sing ///\\\ harvard,ll-xn,rutgers,seismo,
We will sing our own song." -UB40 _||_ topaz}!rochester!ur-valhalla!badrichris@mimsy.UUCP (02/14/87)
In article <1010@ur-valhalla.UUCP> badri@ur-valhalla.UUCP (Badri Lokanathan) writes: >Wire1 (Works) >text data bss dec hex >384000 66560 6071296 6521856 638400 >Wire2 (Does not work) >text data bss dec hex >384000 66560 6988076 7438636 71812c >ctod(ds) = 12906 exceeds maxdmap = 12256 in /sys/machine/vm_machdep.c maxdmap can be computed as a function of DMMIN, DMMAX, and NDMAP. `dmap's are swap allocation chunks. Swap space is allocated in contiguous chunks of varying sizes, increasing by powers of two from DMMIN to DMMAX, then repeating at DMMAX. Your DMMIN is 32, your DMMAX is 1024, and your NDMAP is 16: maxdmap = 32+64+128+256+512+11*1024 = 12256 which is 12256*512 = 6275072 bytes of data space. The way to alter this limit is to change any of those parameters. Making DMMIN 64 will cause more fragmentation, but will give you a maxdmap of 13248; making DMMAX 2048 instead will change it to 22496, or 11517952 bytes. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu
mangler@cit-vax.UUCP (02/16/87)
In article <5433@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > maxdmap can be computed as a function of DMMIN, DMMAX, and NDMAP. > .... > The way to alter this limit is to change any of those parameters. If you increase NDMAP, you will probably have to raise UPAGES in order to leave enough room in the u-area for the kernel stack. There is also some hardcoded stuff in locore.s that has to be changed when you change UPAGES. You also have to recompile just about everything that looks in /dev/kmem or core images. You also need to raise MAXDSIZ. If you go beyond 32 megabytes, you have to increase the size of c_page in cmap.h. (I spent a great deal of time two years ago finding this out the hard way). It is *much* easier to just raise DMMAX, if you can afford more wasted swap space. The wasted space comes about because large processes are rounded up to DMMAX disk sectors of swap space. The useful values are: DMMAX=1024 MAXDSIZ=12*1024-32-SLOP (6 MB) DMMAX=2048 MAXDSIZ=22*1024-32-SLOP (11 MB) DMMAX=4096 MAXDSIZ=40*1024-32-SLOP (20 MB) DMMAX=8192 MAXDSIZ=72*1024-32-SLOP (36 MB) DMMAX=16384 MAXDSIZ=128*1024-32-SLOP (64 MB) In 4.3 BSD, DMMAX is 4096 (and NDMAP is larger). If you don't need a huge increase, just use DMMAX=2048. Don Speck speck@vlsi.caltech.edu {seismo,rutgers,ames}!cit-vax!speck