: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
