From owner-freebsd-platforms Tue Mar 18 10:07:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA13332 for platforms-outgoing; Tue, 18 Mar 1997 10:07:24 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA13324 for ; Tue, 18 Mar 1997 10:07:20 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA09814; Tue, 18 Mar 1997 10:52:09 -0700 From: Terry Lambert Message-Id: <199703181752.KAA09814@phaeton.artisoft.com> Subject: Re: To share or not share ? (was: Someone working on a SPARC version?) To: toor@dyson.iquest.net (John S. Dyson) Date: Tue, 18 Mar 1997 10:52:09 -0700 (MST) Cc: pgiffuni@fps.biblos.unal.edu.co, terry@lambert.org, jb@cimlogic.com.au, srn@flibble.psrg.cs.usyd.edu.au, freebsd-platforms@freebsd.org In-Reply-To: <199703180600.BAA02319@dyson.iquest.net> from "John S. Dyson" at Mar 18, 97 01:00:33 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-platforms@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > It is true that the interfaces in the VM system have changed (and are > therefore FreeBSD specific), but those interfaces are part of the > improvements associated with the VM code. Changing the interfaces > isn't all that difficult, and the hardest part about a port of the > VM code is likely the pmap module changes. One really bad thing > about the original VM code is that the pmap code is called lots > and lots of times. We have mitigated that significantly. Yes; the pmap code is the major barrier, especially on RISC processors where the full VM capability is not all in hardware, and requires some software to go with it. This (and the publically undocumented PPCBug) are where my PPC code is currently bogged. Without the PPCBug code, though, I don't have a reliable console, so I've only mentioned this to you once or twice. > Frankly, it is likely that a VM system that performs as well as > the FreeBSD VM code (and I am not making any relative claims here -- > the other *BSDs are making some improvements), is going to require > interface changes relative to the original Lite/2 code. Yes. There are also issues to be considered re: soft updates, if that code is ever brought in. In a unified VM, soft updates at the FS level (as in the Ganger/Patt implementation) will degrade to DOW performance (cv: our other discussion). I'd like to see some incentives for rethinking the soft updates strategy (it would also avoid the code duplication necessary in an incremental, per-FS approach). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.