Path: utzoo!attcan!uunet!lll-winken!ames!killer!vector!rpp386!jfh
From: jfh@rpp386.Dallas.TX.US (John F. Haugh II)
Newsgroups: comp.unix.wizards
Subject: Re: System V.2 and growing processes
Summary: 7th Edition kernel was deficient.
	 The hardware was just fine.
Message-ID: <11050@rpp386.Dallas.TX.US>
Date: 14 Jan 89 17:46:13 GMT
References: <627@cimcor.mn.org> <6936@june.cs.washington.edu>
Reply-To: jfh@rpp386.Dallas.TX.US (John F. Haugh II)
Organization: River Parishes Programming, Dallas TX
Lines: 64

In article <6936@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes:
>          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.

This decision was based more on keeping the kernel simple [ apparently,
my name is not Dennis Ritchie ;-) ] than due to hardware.  The MMU
registers on 11's with memory management were capable of separating the
stack and data segments, or in scattering the data pages throughtout
memory.  The kernel COULD have gotten this correct, it just didn't.

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

This is correct, but only for the reasons you outlined.  Many process
do not perform raw I/O, so there is little need to insure a process is
accessible to the device controller.  The kernel could have handled the
special case and given the performance advantage to the others.

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

More is needed than munging malloc or sbreak.  Malloc has no way of
know if you are trying to expand into an adjacent region as sbreak
doesn't even provide this information.  Something like

	if (! (seg = realloc (seg, size)))
		mfree (seg);
		seg = malloc (size);
	}
	return (seg);

was needed.  [ The arguments to malloc are the map and the size, the
old region is never even mentioned ... ]

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

I modified malloc to perform any of first, best and worst allocations.
First was so-so, for the reasons given.  Best was even worse, for more
of the reasons given ;-).  The best allocation scheme I found, in the
presence of a realloc-style modification, was find-worst-fit.  It
reduced swapping to an apparent minimum because there were all these
little holes left about.  Growing processes filled up the holes as
needed, instead of being wedged into a space it was unable to grow
inside of.  [ modulo number of users - in a single user environment
worst-fit smelt a lot like any other fit. ]

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

True.
-- 
John F. Haugh II                        +-Quote of the Week:-------------------
VoiceNet: (214) 250-3311   Data: -6272  |"UNIX doesn't have bugs,
InterNet: jfh@rpp386.Dallas.TX.US       |         UNIX is a bug."
UucpNet : <backbone>!killer!rpp386!jfh  +--------------------------------------