:The way this is done in the still-in-development branch of NetBSD's :unified buffer cache is to basically elimiate the old buffer cache :interface for vnode read/write completely. When you want to do that :sort of I/O to a vnode, you simply map a window of the object into :KVA space (via ubc_alloc()), do the uiomove (lettings the pages fault :in as necessary, getting added to the vnode's memq), and release the :window (via ubc_release()). The actual window mappings themselves can :persist, as well (although those mappings are nuked immediately if the :vnode is marked VTEXT on VAC machines, to eliminate bad cache interactions).
Effectively this is what a piece of our buffer cache code does now. The problem is the other 60% of the buffer cache code that does the more complex stuff. I'd like to see our buffer cache devolve into just the I/O and mapping piece. Now, I also believe that when UVM maps those pages, it makes them copy-on-write so I/O can be initiated on the data without having to stall anyone attempting to make further modifications to the VM object. Is this correct? This is something I would like to throw into FreeBSD at some point. It would get rid of all the freeze/bogus-page hacks already in there and avoid a number of I/O blocking conditions that we currently face. However, I do not like the idea of taking page faults in kernel mode, which I believe UVM also does -- but I think the above could be implemented in FreeBSD without taking page faults. :In addition, as described in the UVM paper at USENIX, placing the :object directly in the vnode (which requires a somewhat fundamental :change in the objects, at least nuking the concept of object chains) Well, I do not like the "nuke the object chains" part of UVM. From what I can tell UVM is doing a considerable amount of extra work to avoid the object chain stuff, but only saving a small amount of overhead on vm_fault's ( though, compared to the original Mach stuff the UVM stuff is much, much better ). We've made a considerable number of improvements to our vm_object's in the last few months. But I do like the idea of a VM-specific substructure for vnodes and I do agree that embedding the master VM object in the vnode is a good idea. -Matt Matthew Dillon <dil...@backplane.com> :allows a mapped file's pages to persist in the page cache as long as :the vnode itself is not recycled, as opposed to they annoying limit :on persisting vnode objects that used to exist in NetBSD's Mach VM. : : -- Jason R. Thorpe <thor...@nas.nasa.gov> : : To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message