System V.2 and growing processes

[John F. Haugh II]

In article <8680 at alice.UUCP> debra at alice.UUCP () writes:
>In article <627 at cimcor.mn.org> 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.

The UNIX kernel does not contain a realloc()-like call.  For swapping
kernels, the only routines which are present are malloc() and free().

A process which wishes to grow may not do so by allocating adjacent
memory.  It must be able to allocate a new contiguous region of core
or be swapped.  It would be possible to avoid this behavior if a
realloc existed by testing for available memory at higher or lower
addresses adjacent to the growing process.  This is not done.

>>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.

Well, now you know ;-)  Had a realloc been added these problems wouldn't
exist.  I had added a realloc() which tested for adjacency and it resolved
this problem partially.  The conclusion I reached was that processes
should allocate physical memory in large chunks and then manage the
unused space, rather than growing one click at a time.

>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.

The behavior on the 68K box is due to having a process exceed half the
size of the available memory.  You can't have a free space available
which would be large than the current allocation if you are already
allocating more than half of the free memory.  Only the government is
allowed to use all three halves of anything ;-)

I believe the difference with your Xenix box is because of the difference
in the architecture.  A segment may only be 64K, so you would not swap
until there were no longer any free 64K regions.  Other architecures
require contiguous memory, the 80286 doesn't.

>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):

What you didn't mention is that this may be corrected with the addition
of a routine to perform the realloc() function.  The code addition is
extremely small, and with a simplification that the region never grow
down, very little table munging need be performed.
-- 
John F. Haugh II                        +-Quote of the Week:-------------------
VoiceNet: (214) 250-3311   Data: -6272  |"Now with 12 percent less fat than
InterNet: jfh at rpp386.Dallas.TX.US       | last years model ..."
UucpNet : <backbone>!killer!rpp386!jfh  +--------------------------------------