On Wed, 7 Jul 1999 17:03:16 -0700 (PDT)
Matthew Dillon <dil...@apollo.backplane.com> wrote:
> If this could result in a smaller overall structure, it may be worth it.
> To really make the combined structure smaller we would also have to
> pair-down the fields in both structures. For example, the vnode
> structure
> contains a lot of temporary clustering fields that could be removed
> entirely if clustering operations are done at the time of the actual I/O
> rather then before hand ( which leads to other problems related to
> low-memory deadlocks :-(... but assuming that could be fixed... ).
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).
Clustering is done by the same clustered pagein/pageout that already
exists in UVM.
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)
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
