chris@ubeaut.enet.dec.com (Chris Jankowski) (05/07/91)
(I am cross posting this to comp.arch as it seems to be a general operating system issue.) In article <1991Apr30.160331.16215@milton.u.washington.edu> corey@milton.u.washington.edu (Corey Satten) describes certain behaviour of Ultrix 4.? virtual memory subsystem and the way to tune the system. I think that he also suggests that Ultrix 4.? uses pretty much standard BSD 4.3 algorithms in this area. This raises interesting questions: 1. Did other vendors (who derived their commercial U*X offerings from BSD) modify or tune the virtual memory subsystem to significant extent perhaps providing new nifty algorithms? 2. What does it looks like for ATT System V rel. 3 and 4? Do they have very different virtual memory management? 3. What is the state of the art in this area considering vastly increased demands on the virtual memory subsystem imposed by X.11, RDBMS, transaction processing and the like applications? 4. Do other operating systems using virtual memory approach differ much in the way of the algorithms used for virtual memory management? Enquiring minds would like to know. +-+-+-+-+-+-+-+ Chris Jankowski - Open Systems Eng.- chris@ubeaut.enet.dec.com |d|i|g|i|t|a|l| Digital Equipment Corporation (Australia) tel.+61 3 655 5622 +-+-+-+-+-+-+-+ 45 Exibition St, Melbourne 3000, AUSTRALIA fax +61 3 655 5655 ... and in the last 50 years ... there has never been a famine in a country with a free press - Lawrence Summers - chief economist - World Bank
gwyn@smoke.brl.mil (Doug Gwyn) (05/11/91)
In article <1991May7.065338.1027@ubeaut.enet.dec.com> chris@ubeaut.enet.dec.com (Chris Jankowski) writes: >1. Did other vendors (who derived their commercial U*X offerings from >BSD) modify or tune the virtual memory subsystem to significant >extent perhaps providing new nifty algorithms? Other than Sun, almost all ports of 4.nBSD have had to overhaul the virtual memory code, which was written quite narrowly for a VAX-like VM system. (Sun simply BUILT a VAX-like VM system!) >2. What does it looks like for ATT System V rel. 3 and 4? >Do they have very different virtual memory management? Yes, and furthermore SVR3 and SVR4 differ from each other. SVR3 used a region-based scheme (similar to VAX/VMS), while SVR4 uses an adaptation of SunOS's VM system. The region scheme is, I believe, portable to a wider range of architectures. >3. What is the state of the art in this area considering vastly >increased demands on the virtual memory subsystem imposed by >X.11, RDBMS, transaction processing and the like applications? Shared libraries and dynamic linking have had a bigger effect than silly applications. In general, if the sum of all task sizes exceeds the amount of physical memory by very much (say a factor of two), the system is likely to bog down no matter what VM algorithms are employed. >4. Do other operating systems using virtual memory approach differ >much in the way of the algorithms used for virtual memory management? Yes.
torek@elf.ee.lbl.gov (Chris Torek) (05/11/91)
In article <16121@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >Other than Sun, almost all ports of 4.nBSD have had to overhaul the >virtual memory code, which was written quite narrowly for a VAX-like >VM system. (Sun simply BUILT a VAX-like VM system!) Well no: while the old VM was rather icky and somewhat painful to modify for 3-level schemes such as the i386 and 68030, it did work pretty well for anything that had hardware PTEs. Sun did not build a VAX-like VM system, if by `system' you mean `MMU'; the Sun MMU is much more like a TLB. What they did, rather, was make software PTEs that simulated a VAX. The current BSD development systems have a Mach-based VM (with a few, ah, `interesting' bugs) which is scheduled to change rather a lot over the next few months.... -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
torek@elf.ee.lbl.gov (Chris Torek) (05/11/91)
In article <13087@dog.ee.lbl.gov> I wrote: >The current BSD development systems have a Mach-based VM (with a few, >ah, `interesting' bugs) ... On rereading this it might be taken to imply that the bugs were in the original Mach VM. This may be partly true; the code is derived from the Mach 2.5 VM, not the 3.0 VM, and any bugs fixed in between may still be there. Some of the bugs were no doubt added in the process of `gluing together' the old and new software; this is one reason for the imminent changes I mentioned. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
vandys@sequent.com (Andrew Valencia) (05/11/91)
torek@elf.ee.lbl.gov (Chris Torek) writes: >Well no: while the old VM was rather icky and somewhat painful to >modify for 3-level schemes such as the i386 and 68030, it did work >pretty well for anything that had hardware PTEs. Actually the '030 can do both 2- and 3-level tables. The kicker was the '040 which can only do 3-level. Rumor has it that they did this because they felt they didn't have the real estate to do it both ways on the chip. They went for 3-level because they felt it better addressed the low end--low end, 68040, go figure. I probably don't have the complete story, could someone from Moto flesh this out? The i386 is only 2-level page tables. I guess you could call it 3-level if you count the segmentation. But most companies just make that a flat 32-bit segment and forget about it. Andy Valencia vandys@sequent.com Disclaimer: these are only my opinions, and probably completely wrong at that.
dennis@gpu.utcs.utoronto.ca (Dennis Ferguson) (05/12/91)
In article <13087@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: >In article <16121@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >>Other than Sun, almost all ports of 4.nBSD have had to overhaul the >>virtual memory code, which was written quite narrowly for a VAX-like >>VM system. (Sun simply BUILT a VAX-like VM system!) > >Well no: while the old VM was rather icky and somewhat painful to >modify for 3-level schemes such as the i386 and 68030, it did work >pretty well for anything that had hardware PTEs. > >Sun did not build a VAX-like VM system, if by `system' you mean `MMU'; >the Sun MMU is much more like a TLB. What they did, rather, was make >software PTEs that simulated a VAX. The IBM RT, with its inverted page tables, was another one for which the port of 4.x BSD was done by implementing VAX-like PTEs in software. As efficient text sharing had to be implemented by moving the data up into a different (256 Mb) segment from the text, the macros for converting from VAX-style PTEs, where the data PTEs are contiguous with text, to memory addresses and back became extremely ugly. While functional, the end result was pretty disgusting. >The current BSD development systems have a Mach-based VM (with a few, >ah, `interesting' bugs) which is scheduled to change rather a lot over >the next few months.... One merit of the old BSD VM with respect to the RT (if lack of function can be called a "merit") is that it didn't try to do anything fancy. Inverted page tables really suck for implementing things like copy-on-write forks, and are pretty awful for sharing memory in general unless you can arrange it so that shared objects are usually kept segment-aligned. The RT (and the RS/6000, which inherited the same memory management) probably makes a pretty good test case for the generality of a "portable" VM subsystem since its MMU is quite unconventional. Dennis Ferguson University of Toronto