Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!bbn!uwmcsd1!marque!roger
From: roger@marque.mu.edu (Roger Abrahams)
Newsgroups: comp.sys.att
Subject: Re: UNIXpc per-process VM limit (Was: Re: Swapping and wmgr)
Message-ID: <156@marque.mu.edu>
Date: 31 May 88 03:19:20 GMT
References: <3030@crash.cts.com> <365@manta.UUCP> <1002@umbc3.UMD.EDU>
Reply-To: roger@marque.UUCP (Roger Abrahams)
Organization: Marquette University, Milwaukee, WI
Lines: 101

In article <1002@umbc3.UMD.EDU> alex@umbc3.UMD.EDU (Alex S. Crain) writes:
<In article <365@manta.UUCP> brant@manta.UUCP (Brant Cheikes) writes:
<>In article <3030@crash.cts.com> ford@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@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@umbc3.umd.edu
<alex@umbc3.umd.edu

I think this is important enough to leave the entire original message and 
replies intact.  Sorry for the extra bandwith but this group enjoys a more 
limited distribution.

I am curious where the 0x37f000 number comnes from.  I assume that this is
from the ifile header (see .ifiles in the /lib directory).  If so, my current
3.51 version has an entirely different number.  It is 0x037ff000, which
translates to 58,716,160 decimal or 57.34 megs.  Obviously the machine is
incapable of this kind of space, even with 4 megs of memory and all kinds
of swap space.  The curious thing, for me, was the original posting of the
game "Omega".  This contained a 40-level dungeon.  The final file size was
(as I remeber) aroud 2.5 megs and the load size was close to 40megs.  We
actually got the thing to run, but ONLY with the shared library.  This
would seem to imply an ability to handle images larger than expected.
(Please note that the current version of Omega is entirely different, we had
a few laughs when we suspected that it was installed on some VAX's without
the actual load size being checked, a few of these could wipe out an 
entire university's computer system in short order.)

						- Roger

Newsgroups: comp.sys.att
Subject: Re: UNIXpc per-process VM limit (Was: Re: Swapping and wmgr)
Summary: 
Expires: 
References: <3030@crash.cts.com> <365@manta.UUCP> <1002@umbc3.UMD.EDU>
Sender: 
Reply-To: roger@marque.UUCP (Roger Abrahams)
Followup-To: 
Distribution: 
Organization: Marquette University, Milwaukee, WI
Keywords: