From owner-freebsd-smp  Sat Dec 14 14:02:12 1996
Return-Path: <owner-smp>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id OAA18389
          for smp-outgoing; Sat, 14 Dec 1996 14:02:12 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA18374;
          Sat, 14 Dec 1996 14:02:06 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA22308; Sat, 14 Dec 1996 14:38:54 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199612142138.OAA22308@phaeton.artisoft.com>
Subject: Re: some questions concerning TLB shootdowns in FreeBSD
To: toor@dyson.iquest.net (John S. Dyson)
Date: Sat, 14 Dec 1996 14:38:54 -0700 (MST)
Cc: terry@lambert.org, phk@critter.tfs.com, dyson@freebsd.org,
        peter@spinner.dialix.com, smp@freebsd.org, haertel@ichips.intel.com
In-Reply-To: <199612142154.QAA05435@dyson.iquest.net> from "John S. Dyson" at Dec 14, 96 04:54:09 pm
X-Mailer: ELM [version 2.4 PL24]
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

> > This would let us do device/offset as well as vnode/offset based caching
> > (for instance, hanging all cache buffers for vnodes on a device off the
> > device vnode).
> > 
> > I've wanted this for some time, since I am determined that vclean must
> > die...
>
> 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).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.