From owner-freebsd-current Sun Sep 10 10:08:50 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA10533 for current-outgoing; Sun, 10 Sep 1995 10:08:50 -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 KAA10517 for ; Sun, 10 Sep 1995 10:08:47 -0700 Received: from corbin.Root.COM (corbin [198.145.90.34]) by Root.COM (8.6.12/8.6.5) with ESMTP id KAA12289; Sun, 10 Sep 1995 10:07:33 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id KAA02726; Sun, 10 Sep 1995 10:09:45 -0700 Message-Id: <199509101709.KAA02726@corbin.Root.COM> To: jleppek@suw2k.ess.harris.com (James Leppek), freebsd-current@freefall.freebsd.org Subject: Re: Sig 11 and -current problems. In-reply-to: Your message of "Sun, 10 Sep 95 09:54:40 PDT." <199509101654.JAA02698@corbin.Root.COM> From: David Greenman Reply-To: davidg@Root.COM Date: Sun, 10 Sep 1995 10:09:44 -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 ^^^^^^ Should be "worse". Sory about that... >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 -DG