pwy@pyuxe.UUCP (Peyton Yanchurak) (05/09/88)
In article <142700033@occrsh.ATT.COM>, rjd@occrsh.ATT.COM writes: > > ::> > ::> Does anyone know of a way to figure out how much swap space is in > ::> use under System V? I added the sticky bit to my shells and vi. Now I > ::On System V Release 2 Version 2 (paging) and later releases, the > ::sar command has the -r option. It tell how much memory and also > ::how much swap space is currently available. It gives > ::you a history of free memory and swap space. > :: > :: Peyton Yanchurak > Peyton, > Sorry, Unix System V release 2 is swapping. Release 3 is paging.... > > Randy Sorry, although System V Release 3 and its derivatives are paging releases, paging first appeared in a System V Release with System V Release 2 Version 2 for the VAX at about December of 1984. Shortly thereafter a provisional paging release for the 3B20 came out (System V Release 2 Version 4). The official paging Release for the 3B20 (System V Release 2.1 Version 3) came out at about December of 1985. Also at the year end of 1985 time frame, System V Release 2.1 for the 3B2 (also a paging release) came out. The content of pre 1985 releases of System V are confusing because the same version numbers on the VAX and 3B20 hardware had different meanings. As and example, System V Release 2 Version 2 for the 3B20 was a swaping release (this release had new diagnostics and I believe support for a floating point accelerator); there was no counterpart for the VAX. Also System V Release 2.0 Version 3 for the 3B20 added support for 3b20 specific hardware features. Peyton Yanchurak
bob@cloud9.UUCP (Bob Toxen) (05/11/88)
About five years after Berkeley came out with it!
--
Bob Toxen {ucbvax!ihnp4,harvard,cloud9!es}!anvil!cavu!bob
Stratus Computer, Marlboro, MA
Pilot to Copilot: What's a mountain goat doing way up here in a cloud bank?gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/13/88)
In article <382@cloud9.UUCP> bob@cloud9.UUCP (Bob Toxen) writes: >About five years after Berkeley came out with it! So? Performance tests showed no significant performance advantage of demand paging over the then-current UNIX System V scheme of partial swapping. It was not until the additional advantages of an organized scheme like the UNIX System V region-oriented approach became apparent (e.g. shared libraries) that there was reason enough to implement it. Conversations I've had with kernel implementors indicate that, modulo a few glitches that can be readily corrected, the UNIX System V scheme (which resembles VMS's) is on the right track, and that Babaoglu's scheme embedded in 4BSD often has to be totally replaced. (Sun designed their original memory management hardware to look virtually the same as the VAX's, to avoid this. Not everyone has had that option.)
guy@gorodish.UUCP (05/13/88)
> So? Performance tests showed no significant performance advantage of > demand paging over the then-current UNIX System V scheme of partial > swapping. Umm, I don't even think System V had been *released* when the original paging BSD releases came out. I believe one of the papers on the BSD paging code indicated that there *was* a performance benefit over the 32V partial swapping scheme for large jobs. It was not until the additional advantages of an organized > scheme like the UNIX System V region-oriented approach became apparent > (e.g. shared libraries) that there was reason enough to implement it. The first paging S5 releases didn't have shared libraries; that arrived later. Are you certain that the organizational advantages of a less *ad hoc* scheme were the *only* reasons they went to paging? I doubt that. > Conversations I've had with kernel implementors indicate that, modulo > a few glitches that can be readily corrected, the UNIX System V scheme > (which resembles VMS's) is on the right track, and that Babaoglu's > scheme embedded in 4BSD often has to be totally replaced. (Sun > designed their original memory management hardware to look virtually > the same as the VAX's, to avoid this. Not everyone has had that option.) This is, as somebody pointed out, complete nonsense. The Sun MMU looks nothing like the VAX MMU; the pre-4.0 VM implementation has code to sort of emulate the VAX MMU on a Sun. The 4.0 VM implementation (which is not region-oriented, but page-oriented, although shared libraries were implemented atop it) was also designed to be portable. (So far, implementations exist for the Sun MMU, the 80386 on-chip MMU, and the IBM 370-style MMU.)
lance@Roma.orc.olivetti.com (Lance Berc) (05/13/88)
In article <7878@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >(Sun >designed their original memory management hardware to look virtually >the same as the VAX's, to avoid this. Not everyone has had that option.) The memory hardware of Vaxen and Suns (at least twos and threes) are COMPLETELY different. The only similarity is that Sun-2s support separate control bits for RW(X?) for both user and supervisor, and that both have two levels of tables involved in virtual to physical address calculation. Sun-3s have only two protection bits: read/write and user/supervisor (just like the 80386...). Vaxen have both a real-mode (mapping disabled) and TLBs, Suns don't have either (all references go through the mapping hardware, which is fast enough to eliminate the need for a TLB, at least on Sun-2s). Vaxen have page tables in main memory, with pageable secondary page tables. Suns have mapping information in specially accessed fast memory, and have a cache of eight adress space `contexts'. If a Sun requires a ninth address space then an entire context description has to be swapped out. And to ice the cake, Suns even have Reference Bits! lance Lance M. Berc Phone: (415) 496-6248 Olivetti Research Center Internet: lance@orc.olivetti.com, or 2882 Sand Hill Road, Suite 210 lance%orc.uucp@unix.sri.com Menlo Park, CA 94025 UUCP: {acornrc,oliveb,sri-unix}!orc!lance
gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/14/88)
In article <21688@oliveb.olivetti.com> lance@Roma.UUCP (Lance Berc) writes: >In article <7878@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>(Sun designed their original memory management hardware to look virtually >>the same as the VAX's, to avoid this. Not everyone has had that option.) >The memory hardware of Vaxen and Suns (at least twos and threes) are >COMPLETELY different. While possibly true, it's irrelevant. Notice the word "original" in my posting. I have to admit I don't have "Sun-1" hardware documentation; my conclusion was drawn from perusing the memory management sections of the 4.1BSD source code as adapted to the original Sun computer. By now both Sun and Berkeley have had time to improve the virtual memory model. My point was that it started out a VAX-specific mess.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/14/88)
In article <53104@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: >> So? Performance tests showed no significant performance advantage of >> demand paging over the then-current UNIX System V scheme of partial >> swapping. >Umm, I don't even think System V had been *released* when the original paging >BSD releases came out. Nor did I claim this. >I believe one of the papers on the BSD paging code >indicated that there *was* a performance benefit over the 32V partial swapping >scheme for large jobs. And the AT&T study also showed that for certain types of jobs there could be a measurable improvement. However, there wasn't one for the normal USG UNIX job mix. > It was not until the additional advantages of an organized >> scheme like the UNIX System V region-oriented approach became apparent >> (e.g. shared libraries) that there was reason enough to implement it. >The first paging S5 releases didn't have shared libraries; that arrived later. >Are you certain that the organizational advantages of a less *ad hoc* scheme >were the *only* reasons they went to paging? I doubt that. Again, you're trying to refute things I didn't say. My conversations years ago with people like Larry Brown led me to conclude that they indeed were more swayed by such considerations than by "performance" arguments. AT&T's announced goal of the paging version to to have NO WORSE performance than the partial swapping version. (The emphasis was theirs.) >> Conversations I've had with kernel implementors indicate that, modulo >> a few glitches that can be readily corrected, the UNIX System V scheme >> (which resembles VMS's) is on the right track, and that Babaoglu's >> scheme embedded in 4BSD often has to be totally replaced. (Sun >> designed their original memory management hardware to look virtually >> the same as the VAX's, to avoid this. Not everyone has had that option.) >This is, as somebody pointed out, complete nonsense. The Sun MMU looks nothing >like the VAX MMU; the pre-4.0 VM implementation has code to sort of emulate the >VAX MMU on a Sun. Okay, if that is the case then it still supports the point I was making, which is that the 4BSD virtual memory scheme was quite heavily tied to the VAX design. Apparently the Sun(-1) MMU provided enough hooks for a VAX emulation to work, but other vendors of super-mini class machines have not always found this to be the case for their MMUs (at least not without unacceptable performance penalties, e.g. overly-large reference- bit tables). DMR mentioned to me not too long ago that the Bell Labs research folks had also thought that replacing the 4BSD memory management scheme in their system (which evolved from an early Berkeley VAX release) would be worth doing, just that they hadn't found the time. Perhaps SunOS 4.0 VM is a lot better; it's hard to tell from here. Without regions, how do you keep track of user-attached segments of memory? By long lists of pages (bit maps)?
levy@ttrdc.UUCP (Daniel R. Levy) (05/14/88)
In article <7878@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: # In article <382@cloud9.UUCP> bob@cloud9.UUCP (Bob Toxen) writes: # >About five years after Berkeley came out with it! # # So? Performance tests showed no significant performance advantage of # demand paging over the then-current UNIX System V scheme of partial # swapping. It was not until the additional advantages of an organized # scheme like the UNIX System V region-oriented approach became apparent # (e.g. shared libraries) that there was reason enough to implement it. # Conversations I've had with kernel implementors indicate that, modulo # a few glitches that can be readily corrected, the UNIX System V scheme # (which resembles VMS's) is on the right track, and that Babaoglu's # scheme embedded in 4BSD often has to be totally replaced. (Sun # designed their original memory management hardware to look virtually # the same as the VAX's, to avoid this. Not everyone has had that option.) There is one very nice thing about SV paging (over swapping) that I have noticed on 3B2 hardware: very large executables start up almost instantly instead of taking many seconds to load. I don't know whether this differential is true for Berkeley or not, or on VAXen, never having used a non-paging Berkeley, or VAX UNIX system. Wizards? -- |------------Dan Levy------------| Path: ihnp4,<most AT&T machines>!ttrdc!levy | AT&T | Weinberg's Principle: An expert is a | Data Systems Group | person who avoids the small errors while |--------Skokie, Illinois--------| sweeping on to the grand fallacy.
chris@mimsy.UUCP (Chris Torek) (05/14/88)
In article <7886@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: >Okay, if that is the case then it still supports the point I was making, >which is that the 4BSD virtual memory scheme was quite heavily tied to >the VAX design. Apparently the Sun(-1) MMU provided enough hooks for a >VAX emulation to work, but other vendors of super-mini class machines >have not always found this to be the case for their MMUs (at least not >without unacceptable performance penalties, e.g. overly-large reference- >bit tables). ?? The Sun-1 ran a swapping kernel. At least, the old Sun 1 box (now holding a Sun 2 CPU, and now known as burble.cs.umd.edu) ran a V7ish system when we first got it. Reference bit tables? Note also that the Berkeley Tahoe port elides the reference bit simulation, using the real reference bit in the Harris/CCI/Sperry PTEs. The work to do that consisted mainly of disabling a few dozen lines of code with `#if vax'. The Tahoe is a virtual address cache machine, too (although it has an `uncache' bit in each PTE, which makes I/O easier). >DMR mentioned to me not too long ago that the Bell Labs research folks >had also thought that replacing the 4BSD memory management scheme in >their system (which evolved from an early Berkeley VAX release) would >be worth doing, just that they hadn't found the time. Even Berkeley thinks so. The code *is* overly Vax-oriented, and is old and creaky and rather messy. But it still matches a large number of real machines. If you have a two-level page table and PTEs, the 4BSD VM code will probably work with only semi-major tweaking :-) . -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
lance@Roma.orc.olivetti.com (Lance Berc) (05/14/88)
In article <7885@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <21688@oliveb.olivetti.com> lance@Roma.UUCP (Lance Berc) writes: >>In article <7878@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>>(Sun designed their original memory management hardware to look virtually >>>the same as the VAX's, to avoid this. Not everyone has had that option.) >>The memory hardware of Vaxen and Suns (at least twos and threes) are >>COMPLETELY different. > >While possibly true, it's irrelevant. Notice the word "original" in my >posting. I have to admit I don't have "Sun-1" hardware documentation; >my conclusion was drawn from perusing the memory management sections of >the 4.1BSD source code as adapted to the original Sun computer. By now >both Sun and Berkeley have had time to improve the virtual memory model. >My point was that it started out a VAX-specific mess. SMI didn't design Sun-1 boards; they were designed for a DARPA VLSI project at Stanford and were later involved in the Network Graphics and SUN (Stanford University Network) projects. There was no thought towards putting Unix (or any other OS, really) onto the hardware at the time they were designed, though some Lucasfilm people did so. The Sun-1s used 68000s only, so they had no virtual memory capability whatsoever. In addition, the page mapping hardware of the Sun-1 didn't look anything like a VAX, either (still no TLB, maps living in fc3 space, not main memory, had only two levels of protection, etc). I admit that programming Sun-[123] memory hardware can be a bit messy, but it's never been a VAX sort of mess. lance Lance M. Berc Phone: (415) 496-6248 Olivetti Research Center Internet: lance@orc.olivetti.com, or 2882 Sand Hill Road, Suite 210 lance%orc.uucp@unix.sri.com Menlo Park, CA 94025 UUCP: {acornrc,oliveb,sri-unix}!orc!lance
ok@quintus.UUCP (Richard A. O'Keefe) (05/14/88)
In article <7878@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <382@cloud9.UUCP> bob@cloud9.UUCP (Bob Toxen) writes: > >About five years after Berkeley came out with it! > > So? Performance tests showed no significant performance advantage of > demand paging over the then-current UNIX System V scheme of partial swapping. Letting 5 users run 3Mbyte programs on a Vax with only 4Mbytes isn't a significant performance advantage? Not fast, true, but at least _possible_.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/15/88)
In article <974@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >Letting 5 users run 3Mbyte programs on a Vax with only 4Mbytes isn't >a significant performance advantage? It wasn't important for the typical USG (UNIX System III) job mix. Berkeley systems tended to be used at universities and research institutions where tasks such as large LISP-based applications and image processing formed a much larger percentage of the desired job mix. As time went on and programmers got generally sloppier, even commercial applications starting demanding large virtual address spaces. This has gotten so far out of hand that some of our most important applications won't even run on several of our virtual memory machines these days!
daryl@ihlpe.ATT.COM (Daryl Monge) (05/15/88)
In article <7878@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <382@cloud9.UUCP> bob@cloud9.UUCP (Bob Toxen) writes: > >About five years after Berkeley came out with it! > > So? Performance tests showed no significant performance advantage of > demand paging over the then-current UNIX System V scheme of partial > swapping. Strongly depends on the problem you are trying to solve, doesn't it. Never place much on performance benchmarks unless it is YOUR application that is being benchmarked. Daryl Monge UUCP: ...!ihnp4!ihcae!daryl AT&T CIS: 72717,65 Bell Labs, Naperville, Ill AT&T 312-979-3603
gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/16/88)
In article <2934@ihlpe.ATT.COM> daryl@ihlpe.ATT.COM (Daryl Monge) writes: >Strongly depends on the problem you are trying to solve, doesn't it. >Never place much on performance benchmarks unless it is YOUR application >that is being benchmarked. Exactly right. The test I referred to was done by USG on what they considered a typical application job mix among their clients. In fact, we opted for 4BSD at BRL instead of some USG derivative when we acquired our first VAX partly because some of our (then) important applications were going to benefit from virtual memory. It didn't take long for people to develop hopelessly BSD-dependent applications, though, so it's hard to dig our way out even if we wanted to.
rbj@icst-cmr.arpa (Root Boy Jim) (05/18/88)
From: Doug Gwyn <gwyn@brl-smoke.arpa> In fact, we opted for 4BSD at BRL instead of some USG derivative when we acquired our first VAX partly because some of our (then) important applications were going to benefit from virtual memory. It didn't take long for people to develop hopelessly BSD-dependent applications, though, so it's hard to dig our way out even if we wanted to. At that time, BSD was vastly superior. It took TPC awhile to ketchup. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement My name is in /usr/dict/words. Is yours?
idall@augean.OZ (Ian Dall) (05/19/88)
In article <7896@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <2934@ihlpe.ATT.COM> daryl@ihlpe.ATT.COM (Daryl Monge) writes: >>Strongly depends on the problem you are trying to solve, doesn't it. >>Never place much on performance benchmarks unless it is YOUR application >>that is being benchmarked. > >Exactly right. The test I referred to was done by USG on what >they considered a typical application job mix among their clients. > . . . > >It didn't take long for people to develop hopelessly BSD-dependent >applications, though, so it's hard to dig our way out even if we >wanted to. And programs are developed to suit the available system. Sometimes what is logically one program is split into small processes communicating though pipes and temporary files etc. If one simply transplants that to a demand paged environment there is not likely to be much performance gain. But if the application is rewritten as fewer larger programs with less communication overhead there may be a performance gain. As someone who has spent a lot of time shoe horning things into PDP-11's 64k address space, I suspect the REAL gain in a demand paged virtual memory system is in programmer productivity rather than program performance. It certainly saves a lot of time not having to worry about overlays or using temporary files etc. If I can have a system with infinite physical memory then maybe I wont care if its paging or not. Till then... -- Ian Dall "In any argument there will be people on your side who you wish were on the other side." idall@augean.oz
ron@topaz.rutgers.edu (Ron Natalie) (05/21/88)
The other problem is that System V didn't have TCP/IP either. Don't let Doug fool you, BSD is still superior to System VRanything. Despite people telling how 5R3 is a world of difference from earlier releases and now a trully reasonable system. It still is not anywhere near as nice as 4.3 BSD for people who have to get real work done rather than just reading Netnews. -Ron
allbery@ncoast.UUCP (Brandon S. Allbery) (05/21/88)
As quoted from <382@cloud9.UUCP> by bob@cloud9.UUCP (Bob Toxen):
+---------------
| About five years after Berkeley came out with it!
+---------------
But AT&T did it right, rather than writing a vfork() kluge!
--
Brandon S. Allbery, moderator of comp.sources.misc
{well!hoptoad,uunet!marque,cbosgd,sun!mandrill}!ncoast!allbery
Delphi: ALLBERY MCI Mail: BALLBERY