Date: Thu, 7 Jan 1999 18:06:27 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: tlambert@primenet.com (Terry Lambert) Cc: dillon@apollo.backplane.com, tlambert@primenet.com, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Message-ID: <199901072306.SAA01091@y.dyson.net> In-Reply-To: <199901072226.PAA11860@usr01.primenet.com> from Terry Lambert at "Jan 7, 99 10:26:37 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert said: > > I also believe that the canonically correct way to deal with MFS > issues (if you *insist* on using an inappropriate FS architecture) > is by providing a device interface to anonymous memory, and creating > the FS on that "device", instead. Clean pages that haven't been > written at all don't need to be instanced, and you will have the > same (effectively) soloution as the current MFS soloution, but > without the current MFS problems. > Take a look at the new filesystem created by Mark Brincombe on the NetBSD team. We are using it at work. > > Works on SunOS. Works on Solaris. If you have a source license, > or sign non-disclosure, John Heidemann will show you the code. > It must have callbacks then OR it doesn't provide mmap coherency at every node in the graph. Alot of implementations through coherency away. Abstract VM management with some of the VFS terminology or concepts is much cleaner. Filesystem vnodes just don't make sense in a general case, and struct bp makes even less sense. > > If there's only one object, there's not a coherency problem. If you > make more than one object, then you need explicit instead of implicit > coherency. If everything you need is in the descriptor, however, > then it's marshallable over *any* interface. Network, or user/kernel > proxy for user space developement environment. > The VFS code would have to have TERRIBLE performance then, if for every page fault, the datastructures are traversed from a vnode standpoint. Of course, Solaris isn't known for performance, is it? If the relationships are set-up, then the vm code can take care of things at fault time (including MESI type protocols.) > > > I agree with you. We just disagree about the method of addressing it. > I think that the method should be similar to what Heidemann has already > demonstrated as working in SunOS and Solaris. I don't think that you > need to add a huge amount of parallel complexity to the VFS VM object > interaction; I think, instead, you need to consider simplifying the > VFS vnode interaction model so that VM complications are unnecessary. > VFS means filesystem -- I suggest being more abstract than that. The capability has to be in the VM code anyway, and if you do it in a VFS layer, then you end up with excess complexity. > > Yeah, VM aliases could be useful somewhere, but I think the VFS system > is one place where they are further down an already wrong road. Think > about a NULLFS layer, and how to make it truly NULL; that's the minimal > set. > NullFS is the wrong way to do it. You have to assume at least a translation layer and all of the coherency issues associated with that. If you don't start from a general situation, then you end up adding hacks on to make it work. All VFS should provide is a file type abstraction, but it shouldn't be layered. Even thinking in terms of files forgets the fact that files are a subset of memory. If you show me where a cache or memory coherency protocol is provided by a VFS layering scheme, then you are speaking the same capabilities. Without that, coherent mmap ends up being a terrible hack. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. 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?199901072306.SAA01091>