Date: Thu, 7 Jan 1999 23:38:27 -0500 (EST) From: Alfred Perlstein <bright@hotjobs.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Terry Lambert <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: <Pine.BSF.4.05.9901072248420.37756-100000@bright.fx.genx.net> In-Reply-To: <199901080320.TAA36935@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Jan 1999, Matthew Dillon wrote: > :um, this doesn't give us a growing MFS and i may be niave about this but > :consider: > : > :FFS requests a block passing in a buffer, the buffer is switched out from > :under the attached vnode and stored in the free list (or possibly the > :'locked' list), a buffer from the Memory device is put in its place and > :the vnode is marked as such. > : > :FFS has the block for a while. > : > :Eventually the block is taken off the LRU list because of the nature of > :the LRU queue, anything removing a block must check the mark to see if > :it's MFS backed. > > Which buffer? The one MFS passed back or the original one that was > replaced? I assume you mean that the original buffer is freed and > we are now talking about the one MFS passed back, currently under > control of FFS, is no longer being used and eventually is ready > to be freed again. Yes, I just thought of a simple idea that may make this a reality, ALL pages returned by MFS are marked dirty so that they are 'flushed' to the MFS disk no matter what. Really nothing is done except the fact that the FFS can not 'steal' pages from the MFS and try to reuse them because they DO belong to the MFS. Just an idea for zero copy. (well single copy, kernel to process, instead of kernel to kernel to process) I think what would have to happen is that MFS would be two parts, a very simple 'vn' over memory driver and a system that would 'taint' the arguments passed into it to ensure that they aren't stolen and hock'd off as a clean buffer. > :In fact this could be a callback function, called in general when ANY > :buffers are reused allowing for other flexibilities, however, this > :callback may already be in place as the "flush to backing store" > :call that's done for traditional devices under FFS. > > In order for the callback to work, especially if you intend this > mechanism to work across VFS layers, the original 'source' of the > buffer must be recorded in the vm_page_t. Otherwise the callback > doesn't know who to call. I _think_ i understand. :/ > > :At this point a buffer must be reattached to this vnode, it can be brought > :over from the free list, or perhaps the original buffer could have been > :placed on the 'locked' list (is this still around?) > > Anything put on a 'free' list is gone. Or you are mis-defining the > function of the 'free' list... it isn't really a free list. I'm sorry, i think i meant the front of the LRU list, ready for reuse. > > The problem with renaming a page isn't with the page being ripped out > from the upper VFS layer, but the fact that the lower VFS layer is > removing the page from its own map and thus 'looses' track of it - > something a vm_alias would solve neatly. I'm not arguing against your proposals. What I understand I find very appealing, I just had an observation about MFS that might be applicable. > > -Matt > > :Maybe this is impossible with what we have, or doesn't make sense sorry. > :I _really_ need to UTSL more. :) > : > :-Alfred > : > :btw, what you and John Dyson are working on sounds trully awesome. I > :really hope you guys consider publishing a paper on it sometime because at > :that point FreeBSD will have moved so far from 4.4BSD, that the reference > :books become very far removed from the actual underlying system. > > That is an excellent idea. The VFS stuff we are flame festing over now > is not something under immediate development... I'm spending the next > 3 months cleaning up the existing VM system first, but something is ... > * vm_meter does not count device objects (such as /dev/mem), because > these really skew the results and make vmstat less useful. > Keep us updated. :) I think i'm finally gaining some insight to how these things work. It sounds like it will be great. -Alfred 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?Pine.BSF.4.05.9901072248420.37756-100000>