System V.2 and growing processes

[Paul De Bra]

In article <627 at cimcor.mn.org> mike at cimcor.mn.org (Michael Grenier) writes:
>I posted this originally to comp.unix.questions but got no reply...
>perhaps a wizard is called for :-)
>
>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.
>
>I can't figure out why the kernel can't just assign the space to the process
>instead of moving the entire process to some new spot in memory which
>gets progressively slower as the process gets bigger.
>
>Is this normal behavior for a System V.2 kernel?

I have noticed a similar behaviour in an old System III box (68000 based)
when a process tried to grow to about 500k on a system with 1Meg of ram.
Although no other processes were active the big process was swapped out and
in each time it wanted to grow. I do believe it is very implementation
dependent. I often run big processes on SCO Xenix 286 and never noticed
any swapping.

Moving the process around in memory is clearly stupid. So is swapping when
there is enough memory. However, the standard Unix swapping algorithm in case
all memory is used is as follows (yes I looked at the source of a non-paging
system):
1) the process that wants more memory is swapped out.
2) other processes that are sleeping are swapped out to free up more memory.
   (if all processes are active the algorithm will swap out active processes
   after a while too)
3) the growing process is swapped in again en continues to run (until it
   wants more memory which is not available, in which we return to 1).
This algorithm is less than optimal :-( because the kernel could just as
well only do step 2 and swap out idle processes to get more memory. However,
there is a catch since the growing process that is waiting to get more
memory is also idle in a way...

Too find out if what you experience is this swapping problem you should run
the program twice: the first run will swap out all idle processes, and they
will not be swapped in again as long as they remain idle. In the second run
you should not experience swapping anymore. (that was the behaviour on the
old System III box) If you still experience swapping you indeed have a brain-
damaged memory management.

Paul.
-- 
------------------------------------------------------
|debra at research.att.com   | uunet!research!debra     |
------------------------------------------------------