brant@manta.UUCP (Brant Cheikes) (05/29/88)
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
alex@umbc3.UMD.EDU (Alex S. Crain) (05/31/88)
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
roger@marque.mu.edu (Roger Abrahams) (05/31/88)
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:
ford@elgar.UUCP (Ford Prefect ) (06/01/88)
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? The manual is more accurate than I was. What I meant to say was that the Unix PC has 4 megabytes of virtual address space per process. 2.5M of that is usable for what most of us think of as "program" memory. The rest is shared library, shared memory, and reserved kernel space (bogus design tradeoff). What I mean by 4 megabytes of virtual address space is that the bottom 22 address lines (including the imaginary A0) coming off the CPU are decoded for user programs and converted into a physical memory location. Actually, all 24 address bits are decoded, but only the kernel is allowed to set the top two. -=] Ford [=- "Once there were parking lots, (In Real Life: Mike Ditto) now it's a peaceful oasis. ford%kenobi@crash.CTS.COM This was a Pizza Hut, ...!sdcsvax!crash!kenobi!ford now it's all covered with daisies." -- Talking Heads
brant@manta.UUCP (Brant Cheikes) (06/02/88)
First, thanks to Michael Ditto and Alex Crain for clarifying the per-process memory allocation and corresponding limits. Now, a wee quibble: In article <1002@umbc3.UMD.EDU> alex@umbc3.UMD.EDU (Alex S. Crain) writes: [...] > 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. [...] > 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... I'm not quite sure what you mean by "not relocateable" here. In fact, if you apply dump(1) to a few of your favorite COFFs, you'll discover that the .lib section has different [pv]addrs in each one. There seems to be a confusion between the location of the shlib in virtual memory and the listed address of the .lib section in a COFF, the latter of which is important to unexec. I discovered thru hacking undump (just posted to unix-pc.sources) that it's straightforward to move the [pv]addrs of the .lib around in the COFF. There's no reason why unexec couldn't be patched to do the same. Also, you say that "shlib is always present." If so, why is the .lib section needed in a COFF in order for that executable to use the shlib? If what you say is true, then it should be possible to link an a.out with the shared lib, then strip off the .lib section without any adverse effect, no? -- Brant Cheikes University of Pennsylvania Department of Computer and Information Science ARPA: brant@linc.cis.upenn.edu, UUCP: ...drexel!manta!brant