From owner-freebsd-hackers  Wed Jul  7 18:21:19 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 2214714D75; Wed,  7 Jul 1999 18:21:06 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id SAA95641;
	Wed, 7 Jul 1999 18:21:03 -0700 (PDT)
	(envelope-from dillon)
Date: Wed, 7 Jul 1999 18:21:03 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199907080121.SAA95641@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 
References:  <199907080023.RAA19330@lestat.nas.nasa.gov>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

: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-hackers" in the body of the message