Date: Wed, 7 Jul 1999 18:21:03 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Jason Thorpe <thorpej@nas.nasa.gov> Cc: Julian Elischer <julian@whistle.com>, David Greenman <dg@root.com>, freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup Message-ID: <199907080121.SAA95641@apollo.backplane.com> References: <199907080023.RAA19330@lestat.nas.nasa.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
<dillon@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 <thorpej@nas.nasa.gov>
:
:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907080121.SAA95641>