chris@mimsy.UUCP (Chris Torek) (05/14/88)
In article <7878@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: >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.) As others have mentioned, the claim about Sun's MMU is nonsense. It is true that the 4BSD paging code is overly Vax-oriented: it assumes such things as page table entries and two-level mappings. Other than that, there is nothing inherently wrong with Berkeley's `clock' pageout scheduler, which is usually what critics claim makes VMS superiour. Indeed, it can be argued that the clock scheme is more `Unix-like' than the working set scheme; on the average, it will give better total machine throughput (this is intuitively obvious to me and I intend not to thrash the subject to death here: that has been done before), though its affect on any individual process is not easily predictable---the clock scheme, which is basically `if the machine is getting short of space, kick out any deadwood', depends on how hard the machine is being pushed, while the working set algorithm is more or less `if the process is over its quota, whittle it down by kicking out its deadwood'. The chief disadvantage of the global algorithm is that administrators cannot easily allocate real memory to any given process. (When you get right down to it, VMS is not strictly working set either. Paging *entirely* by working set quotas is stupid, and VMS is not stupid. [Just darned annoying :-) ]) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/15/88)
In article <11484@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >Indeed, it can be argued that the clock scheme is more `Unix-like' than >the working set scheme; ... That's true. The way I like to view the difference is that under the "working set" scheme, a process competes for memory pages only against itself, whereas under the alternative "global" scheme, all processes compete against each other for memory pages. The former is "fairer" and therefore more suitable for real-time oriented systems, while the latter is arguably more globally efficient and certainly feels more like a traditional UNIX way of doing business.
dave@cs.wisc.edu (Dave Cohrs) (05/16/88)
Even if you were to put a real working set scheme (or even WS-clock,
which might satisfy the spirit-of-UNIX argument you guys brought up)
into UNIX, you'd still need some kind of global policy. You don't want
one process to take over all of memory; remember, working set isn't
fixed sized (which is why the VMS policy isn't really working set, or
wasn't last time I checked), it's defined over a time interval. A
memory load balance policy is necessary, and you still need to swap
processes when memory gets over-committed.
If you have the hardware support, working set, or WS-clock would
probably be a win, even in UNIX. Of course, if your machine doesn't
have enough memory in the first place, no memory management policy is
going to help; you'll need to spend some $$.
Rule #1 in paging: It's great until you have to use it.
--
Dave Cohrs
+1 608 262-6617 UW-Madison Computer Sciences Department
dave@cs.wisc.edu ...!{harvard,ihnp4,rutgers,ucbvax}!uwvax!davehedrick@athos.rutgers.edu (Charles Hedrick) (05/20/88)
When discussing SV vs BSD paging, it's interesting to look at the comparison of TOPS-20 with other DEC OS's (VMS and TOPS-10). SV has been compared to VMS (note that I don't know anything independent about it, since I know only SVr2 without paging). In many ways BSD looks more like TOPS-20. The claim was always made that VMS paging, like TOPS-10 paging, was more efficient than TOPS-20 because processes paged only "against themselves". It always seemed that in practice, good performance on VMS requires more adjustment of user-specific parameters. On TOPS-10 (where I have more detailed experience, though years out of date), it seemed that system performance had more of a "knee". With one process paging, the system really did protect other processes against it, but when several processes paged, because no global resource computations were made, you ended up using up all the disk bandwidth, and everybody died. (Of course this may have improved after I left the TOPS-10 community, which is many years ago.) TOPS-20 definitely had more of an overhead than TOPS-10 or VMS, but required no tuning and overloaded "soft". One suspects something similar is likely to be true of BSD vs. SV: that neither is universally superior, but rather than they each have advantages in different circumstances. It might be useful to try to characterize those circumstances rather than decide which is "better". Does anybody know both well enough to have a go at it?