Date: Thu, 5 Mar 1998 19:32:43 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: rminnich@Sarnoff.COM (Ron G. Minnich) Cc: toor@dyson.iquest.net, hackers@FreeBSD.ORG Subject: Re: vm architecture of freebsd. Message-ID: <199803051932.MAA02034@usr06.primenet.com> In-Reply-To: <Pine.SUN.3.91.980305135658.3052D-100000@terra> from "Ron G. Minnich" at Mar 5, 98 02:05:00 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> On Wed, 4 Mar 1998, John S. Dyson wrote: > > What exactly are the specific problems that need to be fixed? > > actually, there's a very long note I sent years ago to the freebsd list on > the problems. There are implementation problems, problems with VFS > interaction (e.g. NFS), but the ones which caused me trouble are > architectural. > > example: last time I checked, you can msync an mmap'ed page, and if it is > backed by NFS, the page is not really purged. The next time you fault on > the page, it's just pulled out of the NFS block cache. That's wrong. But > it's hard to fix because the VM system can't tell the VFS that it should > purge the page from its cache: the information is not available in the > arguments to the VFS from the VM. This is no longer true. Now there is an NFS specific putpages (if my last set of changes was committed, instead of the defaultops "fix" that was suggested as an alternative; I don't know which is the case, having been flooded at work and unable to update my source tree at home). At a minimum, you could call the generic putpages after uncaching the page. > Follow the VM fault path: at each level, information is added as more is > learned, but not all the information is passed down to the lower levels, > such as faulting VA, fault type, etc. This is I suppose good Information > Hiding policy, but it's bad for my needs. Also the VM tends to not > consult the underlying object for a number of cases, the worst one being > that if a write fault occurs on a read-only page, the VM will tend to > add write access without asking the VFS is that is ok. For an example of > how the VM ought to work, see, e.g. SunOS. Yes, I'm serious. The SunOS VM has a number of scaling and other problems. Even if we totally dismiss SMP, this is still an issue for async I/O, kernel threading, and any actual RealTime work that someone might want to do. 8-(. > Anyway this is a years old discussion I have gone into on this group > about once a year, so if there are archives more detail is in them. Since > Chuck Cranor has basically resolved my problems in Open- and Net-BSD, I'm > not as concerned with FreeBSD VM limitations at this point ... Well, I think you shouldn't abandom FreeBSD. You are doing sexy work, and that certainly benefits the community. There have been a number of changes for the better in the specific areas you outline, which will at least make it possible to do something about them, if it doesn't fix things already (I know the uncache fix isn't there...). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803051932.MAA02034>