UNIXpc per-process VM limit (Was: Re: Swapping and wmgr)

[Alex S. Crain]

In article <365 at manta.UUCP> brant at manta.UUCP (Brant Cheikes) writes:
>In article <3030 at crash.cts.com> ford at crash.CTS.COM (Michael Ditto) writes:
>>The Unix PC supports 4M of virtual memory PER PROCESS, with a total amount
>>dependant on your physical memory + swap space.
>
>I would like to see this claim substantiated.  On page 2-1 of the AT&T
>UNIXpc Interface Specification ("Detailed Interface Specification")
>for version 3.51, it says:
>
>	"Minimum real memory is 512K [...] and maximum process
>	size for a virtual memory program is 2.5 megabytes."
>
>Who's correct, the FM or Mr. Ditto?
>-- 
>Brant Cheikes
>University of Pennsylvania
>Department of Computer and Information Science
>ARPA: brant at linc.cis.upenn.edu, UUCP: ...drexel!manta!brant


	Both are correct. The unixpc supports 4mbyte VIRUAL IMAGE AREA. This
what the user program looks like after loading, and includes a certain amount
of system stuff, like the kernal, which must be present as the process is 
running so that it will be present when the process exists or the time slice 
ends.

	kernal memory is 	0x000000 -> 0x080000
	user process is 	0x080000 -> 0x300000
	Shared libraries	0x300000 -> 0x37f000
	kernal dynamic memory	0x380000 -> 0x400000
	Harware page table	0x400000

	Thus user memory is those addresses between 0x080000 and 0x300000,
about 2.5mbytes. 

	There are ways to make this area bigger, if your strapped for memory,
like using the shared libraries. shlib is always present in the user image,
as read only text. So if you link to shlib, you don't have to load the library
calls with -lc, and therefore retrieve that space. Since shlib is always
present, it also means that you don't have to load it at run time, so the
executable file is smaller.

	Unfortunately, shlib loses with programs line emacs, because unexec()
in the emacs code tries to relocate it, and shlib is not relocateable. Someone
could, of course, teach unexec() about shlib...

	Also, not all of the memory is mapped. for example, shlib appears
to only take up about a third of its allocated space, leaving about 300K 
untouched. It may be possible to load something into that space, or increase
the size of shlib to 512K by adding local routines. For example, one could
probably add emacs to shlib (or a good chunk of it), and reduce the size
of the emacs executable to ~2-300k, and cut the startup time to a few seconds.

	If this sounds weird, remember that its already done every time you
load a device driver. The kernal doesn't use all the memory allocated to it
(0x000000 to 0x080000 and above 0x37f000) and saves some for device drivers,
which are loaded AFTER the kernal is started. The kernal knows how much memory
is left over and allocates enough for each driver as it is loaded out of that 
pool.

	I haven't played with this much due to time constraints, and would
like to hear from anyone who does/has. Enjoy.
-- 
					:alex.

nerwin!alex at umbc3.umd.edu
alex at umbc3.umd.edu