Skip site navigation (1)Skip section navigation (2)
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>