System V.2 and growing processes

[Kenneth Almquist]

mike at cimcor.mn.org (Michael Grenier) writes:
> My Microport V/AT box has a very very slow brk/sbrk call. It seems that
> when a process wants to increase its brk value, the entire process must
> be moved in memory or out to swap space EVEN when there is available
> and contigous memory right next to (at higher addresses) the growing process.
>
> Is this normal behavior for a System V.2 kernel?

This approach is the one that is used on the PDP-11.  It works reasonably
well on the PDP-11 because processes are limited to 64K of data on that
machine.  In the PDP-11 scheme the data area (which grows up) is stored
below the stack (which grows down), so when either the stack or the data
area is grown, the process must be moved, even if there is contiguous
memory right next to the growing process.  When UNIX was ported to the VAX,
a different scheme was implemented.  Processes are not stored contiguously
in memory.  Instead, the pages of a process are scattered throughout memory.
Thus the problem you describe does not occur on VAX.

You may wonder why the approach used on the VAX isn't used everywhere.
The answer is that on some machines, devices can only do I/O to contiguous
regions of physical memory.  On these machines, there are two reasons for
keeping processes physically contiguous in memory.  First, since if the
pages of a process are scattered randomly throughout memory on such a
machine, swapping a process requires a separate I/O operation for each
page of the process, which is slow.  Second, raw disk and tape device
drivers which perform DMA directly to the user's address space won't work
if the user process is not contiguous.

Apparently the memory management in your kernel is based upon the PDP-11
code rather than the VAX code, probably for the reasons listed in the
preceding paragraph.

If you have kernel source, you could try modifying the layout of the
process so that the data area came last, and then modifying the sbrk
system call to take advantage of this.  This scheme isn't perfect
since UNIX uses a first fit memory allocation strategy (meaning that
the next process to be loaded into memory is likely to be loaded right
above yours in memory), but on a single user system the growing process
is likely to be the only running process so nothing else is likely to
be swapped in.  Another approach is to implement a hybrid scheme which
always reads processes into contiguous areas of memory initially, but
adds noncontiguous memory to the process when the process allocates
more memory.  If a noncontiguous process tries to do raw disk I/O, you
have a problem.  One solution is to swap the process out, forcing it to
be contiguous when it is swapped back in.

If you have a binary only system, about all you can do is complain to
your vendor.
				Kenneth Almquist