Date: Tue, 5 Jan 1999 18:08:11 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: dyson@iquest.net, tlambert@primenet.com, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Message-ID: <199901052308.SAA01859@y.dyson.net> In-Reply-To: <199901052236.OAA97860@apollo.backplane.com> from Matthew Dillon at "Jan 5, 99 02:36:28 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon said: > > My current argument is to give vm_page_t an aliasing capability - > vm_alias_t's are actually linked into multiple objects and can > alias the same vm_page_t, and thus allows the VM system to maintain > cache coherency between VFS layers up to a break point (e.g. a > file fragment or a VFS device that must translate the contents > of a page, such as RAID-5 or an encryption module), and then use > a more sophisticated (and less efficient) model to bridge the > gaps - aka a cache coherency protocol aka John's 'bidirectional > IPC capability' idea. > Yes, I think that is a good idea (the vm_alias_t's) which support the short circuiting of the complex layering. This is needed for efficiency on local machines. However, this allows for more distributed environements, or less well behaved filesystems, in the worst case. It is good that we are looking at a more general abstraction, and then adding (planned and structured) short-circuit mechanisms for efficiency. This is excellent!!! I think that all of us (including me) have been trying to think of ways to fit the current VFS scheme to reality. That is been irritating to me for quite a while, where I could not come to a reasonable approach or conclusion. Since my break, I have been able to stand back and look at things from a higher level, and finally I just "got tired" of the VFS scheme :-). Since working on the distributed kernel G2, I noticed that such schemes can be liberating. To build a "bidirectional" VM/VFS structure might require a little bit of a supporting infrastructure, but in the longer run, we all will be much more sane :-). -- 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?199901052308.SAA01859>