maximum swap space

[Ruth Milner, Systems Manager x2746]

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 at helios.physics.utoronto.ca