From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: "John S. Dyson" Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit References: <20011025175530.1D4BF19A1C@mail.cse.psu.edu>, <20011025142927.B8085@honk.eecs.harvard.edu> Subject: Re: [9fans] Virtual memory in BSD and Plan9 Date: Mon, 29 Oct 2001 10:16:32 +0000 Topicbox-Message-UUID: 0fe1f4ec-eaca-11e9-9e20-41e7f4b1d025 wkj-despam@eecs.harvard.edu (William Josephson) wrote in message news:<20011025142927.B8085@honk.eecs.harvard.edu>... > On Thu, Oct 25, 2001 at 01:55:25PM -0400, Russ Cox wrote: > > The discussions here were talking about many-years-old > > systems. I don't think anyone even mentioned Plan 9's VM system, > > which is just about the simplest thing you could imagine. > > The BSDs have oodles more ``features.'' I'd look in > > www.researchindex.com for the latest stuff, and in McKusick et al. > > (Design and Implementation of the 4.4BSD OS) for older stuff. > > You can decide for yourself whether Plan 9 needs any of it. > > You probably want to take a look at Charles Cranor's PHd thesis from > Washington on UVM. If I recall correctly, some of the *BSDs (NetBSD, > FreeBSD?) have picked it up or at least borrowed ideas. > FreeBSD and NetBSD have different VM systems. FreeBSD's (which I am the primary implementer), is really a corrected and filled out MACH VM for UNIX. It provides lots of the necessary shortcuts fully virtualized for the process VM forking and things like that. The original MACH VM port really wasn't meant as being production ready (per my discussions with Hibler), but was more of a feasibility exercise. Even though it wasn't fully made robust in the original implementations, it wasn't that much worse than many commercial UNIX VM behaviors. Probably the biggest difference doesn't occur during 'normal' memory resident situations, but where FreeBSD has rather advanced paging stats, and really does put off the thrashfest until the system doesn't have enough pages to supply an adequate resident working set. If there is minimally enough memory, FreeBSD will converge reasonably quickly, without undue thrashing. In my early experiments, it was very satisfying to hear the system 'calm down' after experiencing thrashing due to a necessary change in working set population. Most other systems tended to keep on thrashing for long periods, even when there was obviously enough memory. The pseudo-random pagouts and invalidations from non-FreeBSD systems tended to really screw up the page reference information on memory segments being used by otherwise runnable processes. The relatively good behavior has been especially useful when running user-mode windowing systems, where the blocking from poorly chosen page invalidations can really stop-up the works. Both FreeBSD's VM and NetBSD's VM work pretty well (no real complaints from either party), and most/all of the limitations of the original MACH VM have been expunged. There were even cases of limitations that I thought to be unsolvable in the FreeBSD code eventually simply be an 'exercise in data structures', and the last REAL limitation due to address space/fork inheritance was remedied as a result of competition from NetBSD's new VM stuff. FreeBSDs and NetBSDs code is both adequately portable, and that should not be a deciding issue. Frankly, the most important deciding issue is probably based upon knowledge of the VM code that the individual who might do the port to Plan 9. One might make a 'decision' that the VM shouldn't page anyway (except in odd situations), and so the relative advantages of the two systems becomes less important. My philosophy is based upon the fact that an OS MUST NOT just be a fair weather friend, and from my rather VM-centered viewpoint, I believe that this includes the fact that VM shouldn't randomly thrash, when it could more actively converge to a reasonable working set (when possible.) If starting from scratch, it is really easy to write some code that works. However, there is ALOT more work to making a VM system function under load to maximize availability of CPU cycles. Unfortunately, it is clear that VM system behavior is almost always a secondary priority, because it doesn't specify/benchmark very easily. John