SYSRUTH@utorphys.bitnet (Ruth Milner, Systems Manager x2746) (02/02/89)
I recently asked about making use of swap space which was available but which the system would not allow a process to allocate. One of our more knowledgeable users did some poking around, found the reason, and the problem has now been circumvented. The problem is a combination of three things: 1. the way the OS allocates swap 2. the maximum number of swap segments a process can allocate 3. the maximum size of swap segments Presumably if this problem doesn't exist in 4.0, #1 has changed. At 3.X nothing can be done about it. About #2, the value is currently set to 36, and without source this cannot be changed since it is compiled into various modules. The only other thing that can be done is to change #3. This is done through a variable called dmmax in the kernel. This is normally determined dynamically at boot time when the system examines the available swap space on the devices given in the "config" line. However, if this value is not 0, it will not be adjusted. The answer then was to "adb" the next highest power of 2 into the kernel and reboot. Using adb showed the active value was 4096 (it is measured in disk sectors, not KB), so I patched it in /vmunix to be 8192 and rebooted. The result: 81904k process allocable (before anyone logged on). So far we have not seen any adverse results (no "panic"s) but it has only been up for 2 days. Hopefully someone else can make use of this. Ruth Milner Systems Manager University of Toronto Physics sysruth@helios.physics.utoronto.ca