dunigan@ornl-msr.ARPA (Tom Dunigan) (04/24/85)
What are implications and procedure for permitting a process under 4.2 to have a data segment greater than 6meg? Has anyone done same? thanks tom dunigan dunigan@ornl-msr.arpa
pete@ecrcvax.UUCP (Pete Delaney) (04/25/85)
We are interested in the same problem here. I haven't look'd at the code, however I don't see the reason for the restriction. We run large prolog proc's here and I here users complaining that at times the system won't let there stuff run. In a non-paging system when the exec() does the expand() I think it would swap itself out until memory is available. Then the swapper would bring it in when the memory is available. Perhaps someone would like to elaborate on the algorithm used in a vmunix and why this 6megbyte limit exist. -- Pete Delaney - Rockey Mnt UNIX Consultant Phone: (49) 89 9269-139 European Computer-Industry Research Center UUCP: mcvax!unido!ecrcvax!pete ArabellaStrasse 17 CSNET:pete%ecrcvax@Germany.CSNET D-8000 Muenchen 81, West Germany UUCP Domain: pete@ecrcvax.UUCP X25: (262)-45890040262
chris@umcp-cs.UUCP (Chris Torek) (04/26/85)
The 6 megabyte limit is arbitrary; we run with a much larger limit here (6M text, 16M data, 6M stack). Just increase the values in vax/vmparam.h, and make sure that DMMIN and DMMAX and so forth are big enough. (We have DMMIN = 64, DMMAX = 2048, DMTEXT = 1024, NDMAP = 16.) I *think* that's all you need to worry about.... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
faustus@ucbcad.UUCP (04/27/85)
> What are implications and procedure for permitting a process under > 4.2 to have a data segment greater than 6meg? Has anyone done same? The simplest thing to do now is to wait for 4.3 when you can have up to 64 Meg with very little work... Wayne
mike@brl (Mike Muuss) (04/30/85)
Here is all the information I have on this topic. Most of this came from Utah. -Mike - - - - - - - - - - - - INCREASING DATA/STACK MAXIMUM SIZES The following sets of numbers illustrate ways to increase the limits for virtual memory for data and stack segments. There are two things which must be changed in order to do this. The resource limit MAXDSIZ must be raised to accomodate the largest data segment size desired (although the soft limit need not be raised to the same value). Currently, the hard stack limit is set to MAXDSIZ as well. Also, the swap map per segment, as defined in dmap.h, must be made large enough to map the maximum size data or stack segment (there is one map for each). This is accomplished by changing the number or sizes of the sections of this map, NDMAP and/or DMMAX. max size, MAXDSIZ NDMAP DMMIN DMMAX bytes Mb (pages/blocks) added to u. 6 (default) (12*1024-32-SLOP) 16 32 1024 - 10* (20*1024-32-SLOP) 24 32 1024 64 11 (22*1024-32-SLOP) 16 32 2048 0 12 (24*1024-32-SLOP) 16 64 2048 0 16 (32*1024-32-SLOP) 36 32 1024 160 16* (32*1024-32-SLOP) 21 32 2048 40 20 (40*1024-32-SLOP) 44 32 1024 224 20* (40*1024-32-SLOP) 24 32 2048 40 20* (40*1024-32-SLOP) 16 32 4096 0 * recommended configurations parameter locations: MAXDSIZ vax/vmparam.h NDMAP h/dmap.h DMMAX, DMMIN vax/autoconfig.c Map size calculation: The map contains blocks of size (in pages) DMMIN, DMMIN*2, DMMIN*4, ... to size DMMAX, then the remaining blocks (up to NDMAP) are of size DMMAX. For example, the current sizes give blocks of sizes 32 64 128 256 512 11*1024. The size mapped by a dmap can be determined by counting, or calculated by size = (DMMAX - DMMIN) + (NDMAP - (log2(DMMAX) - log2(DMMIN))) * DMMAX. Considerations: 1. Larger NDMAP increases size of user struct, possibly leaving insufficient room for kernel stack. Could increase UPAGES. Note: most 4.2 systems have a bug in locore.s, sccsid under 6.4; Fastreclaim had UPAGES wired in. This must be fixed to change UPAGES: about line 1160, change subl3 P_SSIZE(r5),$0x3ffff8,r0 to subl3 P_SSIZE(r5),$(0x400000-UPAGES),r0 and subl2 $(0x3ffff8+UPAGES),r4 to subl2 $0x400000,r4 2. Larger DMMAX means larger chunks of swap (interleaving is done in DMMAX sections), thus more fragmentation loss. This requires more than proportional increase in swap area (for 20Mb processes and DMMAX of 4096, 2Mb sections, at least three 32-Mb swap partitions should be provided). Of course, any increase in process size makes greater demands on swap space. 3. Changes to NDMAP and/or UPAGES require recompiling ps, pstat, adb, dbx, etc. 4. I'm not sure that increasing DMMIN works, at least without increasing SLOP. From Mike.Accetta@cmu-cs-ius Sat Jan 14 11:54:55 1984 Date: Thursday, 12 January 1984 11:28:09 EST From: Mike.Accetta@cmu-cs-ius To: ihnp4!houxm!houxf!ho95b!wcs@ucb-vax Cc: info-unix@brl-vgr Subject: Re: How can I get bigger processes on 4.1BSD ? Status: R Bill, What panic message are you getting? You probably also have to change the definition of NDMAP in h/dmap.h. The setup document mentions this file but neglects to describe what constants to change. We were able to use 12Mb data segment sizes after doubling this constant from 16 to 32. To explain, the paging system allocates chunks of paging space for the data segment geometrically beginning with a size of DMMIN up to a maximum of DMMAX. It stores the pointers to the beginning of each of these chunks in the dm_map array. Paging area memory for a large process would thus get allocated something like this: Chunk Size (sectors) 0 32 \ 1 64 | 2 128 | < .5 Mb 3 256 | 4 512 / 5 1024 \ 6 1024 | 7 1024 | 8 1024 | 9 1024 | 10 1024 | 5.5 Mb 11 1024 | 12 1024 | 13 1024 | 14 1024 | 15 1024 / Which as you can see causes the dm_map array to run out of room slightly before the process size can reach 6Mb. By adding another 16 elements to the the end of the array, you gain 16*.5Mb = 8Mb more process address space for a maximum of slightly under 14Mb (actually the minimum number which you need to increase NDMAP by is more like 12 or 13 for 12Mb data segments depending on how you define MAXDSIZ). When you change this constant it is also advisable to recompile the various user programs (w, ps and pstat are the ones that come to mind immediately) which include this file for examining the user area of a process and for grabbing the command line arguments from the paging area when a process is not resident. - Mike Accetta From thomas Sat Jan 14 21:54:44 1984 Received: by utah-cs.ARPA (4.19/3.33.3) id AA03226; Sat, 14 Jan 84 21:54:40 mst Date: Sat, 14 Jan 84 21:54:40 mst From: thomas (Spencer Thomas) Message-Id: <8401150454.AA03226@utah-cs.ARPA> To: lepreau, vax-sys Subject: Increased process sizes Status: R I am increasing the maximum data space for a process from 6MB (approx) to 11MB (approx). This seems to be the easiest alternative size (has the fewest side effects). No programs should need to be recompiled for this change, the only effect is to make fragmentation of swap space a little worse for processes bigger than 1MB (it allocates 1MB chunks instead of 512kb chunks for large processes). If it weren't for the fact that CS is short of swap space, I would increase it to 2MB chunks, giving a total process size of 20Mb, but the recommended amount of swap in this case is 96Mb, about twice what CS has (and, indeed, more than GR or UG have, too). =S