From owner-freebsd-current  Sun Sep 10 09:53:42 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id JAA05090
          for current-outgoing; Sun, 10 Sep 1995 09:53:42 -0700
Received: from Root.COM (implode.Root.COM [198.145.90.17])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA05075
          for <freebsd-current@freefall.freebsd.org>; Sun, 10 Sep 1995 09:53:40 -0700
Received: from corbin.Root.COM (corbin [198.145.90.34]) by Root.COM (8.6.12/8.6.5) with ESMTP id JAA07222; Sun, 10 Sep 1995 09:52:28 -0700
Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id JAA02698; Sun, 10 Sep 1995 09:54:40 -0700
Message-Id: <199509101654.JAA02698@corbin.Root.COM>
To: jleppek@suw2k.ess.harris.com (James Leppek)
cc: freebsd-current@freefall.freebsd.org
Subject: Re: Sig 11 and -current problems. 
In-reply-to: Your message of "Sun, 10 Sep 95 12:21:51 EDT."
             <9509101621.AA01547@borg.ess.harris.com> 
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Sun, 10 Sep 1995 09:54:40 -0700
Sender: current-owner@FreeBSD.org
Precedence: bulk

>I do not think there is a "one pass" solution for the current problem.
>I am also a little puzzled as to how the VM changes(if they are at fault)
>can cause such pervasive problems??? I would have thought they would
>be isolated inside the kernel and outside of most of the binaries...

   Among John's changes were some to the way that fault clusters work. When the
system does clustering, it must determine the number of contiguous blocks on
the disk. If it calculates this number too large, it will page in some garbage.
Once this gets paged in, it will "stick" in the cache until it is flushed. The
affect of this is that machines with lots of memory will tend to work better
than machines with small amounts of memory (because the small memory machines
will flush out the garbage quickly and/or do less aggressive clustering -
avoiding the problem completely).
   The problem *might* be in the new ffs_bmap() routine that now calculates
the amount of "run behind" (the amount of contiguous pages before the
requested block). In any case, the problem sounds very much to be either in
the vnode_pager or related routines (ffs_bmap, etc). I don't have time to look
into this at the moment, but perhaps John will be able to some time soon.

-DG