From owner-freebsd-smp  Sat Dec 14 14:27:22 1996
Return-Path: <owner-smp>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id OAA21484
          for smp-outgoing; Sat, 14 Dec 1996 14:27:22 -0800 (PST)
Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA21471;
          Sat, 14 Dec 1996 14:27:17 -0800 (PST)
Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id RAA05515; Sat, 14 Dec 1996 17:25:55 -0500 (EST)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199612142225.RAA05515@dyson.iquest.net>
Subject: Re: some questions concerning TLB shootdowns in FreeBSD
To: terry@lambert.org (Terry Lambert)
Date: Sat, 14 Dec 1996 17:25:55 -0500 (EST)
Cc: toor@dyson.iquest.net, terry@lambert.org, phk@critter.tfs.com,
        dyson@freebsd.org, peter@spinner.dialix.com, smp@freebsd.org,
        haertel@ichips.intel.com
In-Reply-To: <199612142138.OAA22308@phaeton.artisoft.com> from "Terry Lambert" at Dec 14, 96 02:38:54 pm
X-Mailer: ELM [version 2.4 PL24 ME8]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-smp@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> >
> > Slightly off subject, but I plan to sometime carry the vnode/offset
> > caching to a more generalized scheme that also encompasses device/offset
> > caching.  Specifically, device/offset is the same as vnode/offset.
> > 
> > This will allow us to cache data without the vnode.  However, we will
> > continue to have the advantages of the current vnode/offset scheme.
> 
> This is one of the reasons for murdering vclean: so you can get a cache
> hit on perfectly good data which is in memory, but for which the vnode
> has been reused, freed, destroyed, or whatever.  Without the vnode, the
> perfectly good data can not get a cache hit... it has to be loaded in
> from disk again (potentially tromping other perfectly good data that
> is also in cache, but is older than the perfectly good data we can no
> longer reference -- bletch).
> 
> 
The ONLY reason that it hasn't been done, is (my) time limitations.  Other
things scream louder -- and the "nice" things get left by the wayside.
For example, today I am working on the merge of the Lite/2 stuff (finally).
After the merge, and the commits, I expect that there will be at least
a few days of instability, and guess what I get to do (answer: read
frantic requests for help, look at core dumps, and generally feel bad
about messing up the tree.) :-).

John
dyson@freebsd.org