From owner-freebsd-stable  Tue Jun 25 19:13:37 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id TAA23902
          for stable-outgoing; Tue, 25 Jun 1996 19:13:37 -0700 (PDT)
Received: from deceased.hb.north.de (deceased.hb.north.de [194.94.232.249])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA23895
          for <stable@FreeBSD.org>; Tue, 25 Jun 1996 19:13:33 -0700 (PDT)
Received: from jelal.hb.north.de by deceased.hb.north.de with uucp
	(Smail3.1.93) id m0uYk6R-0016CDC; Wed, 26 Jun 96 04:13:11 +0200 (MET DST)
Received: by jelal.hb.north.de (SMail-ST 0.95gcc/2.5+)
	id AA00231; Wed, 26 Jun 1996 04:07:08 +0100 (CET)
Received: (from nox@localhost) by saturn.hb.north.de (8.7.5/8.7.3) id EAA00706; Wed, 26 Jun 1996 04:08:09 +0200 (MET DST)
From: Juergen Lock <nox@jelal.hb.north.de>
Message-Id: <199606260208.EAA00706@saturn.hb.north.de>
Subject: Re: lockups.
To: davidg@root.com
Date: Wed, 26 Jun 1996 04:08:09 +0200 (MET DST)
Cc: jhay@mikom.csir.co.za, stable@FreeBSD.org
In-Reply-To: <199606250712.AAA03836@root.com> from David Greenman at "Jun 25, 96 00:12:09 am"
X-Mailer: ELM [version 2.4ME+ PL19 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

David Greenman writes:

>    Other than consistency checks, the only change that has been made to the
> pageout daemon was last Wednesday when the RSS limiting code was #if 0'd.
> The code shouldn't have come into play on most systems (since the default
> limit is 1/2 of all memory). The problem is that it might not be safe due to
> the recursive calling nature of the functions that do the trimming and because
> it walks through the 'allproc' list in a potentially dangerous manner.
>    You could try to enable it and see if this is the "night and day"
> difference that you're describing. Change the #if 0 to a #if 1 at the end of
> /sys/vm/vm_pageout.c.

Thats just what i did, and i put back the remove-cached-objects-that-
have-no-RSS code below the #if 0'd part. (havent tried the #if 1 alone)

 i guess its not the rss-above-limit check that makes the big difference
but the one for process-swapped-out?  if its disabled then entries
for swapped out processed remain in the list its traversing, causing
more page faults... up to the point where its doing little else.
am i talking nonsense yet? :)

 btw.  if you have an older version of xperfmon that still has the
`free memory' display then the difference is very obvious...  on a
kernel without the problem (not #if 0'd) when the value hits 0 it
`jumps' back up at (usually) at least 1MB/sec.  on a kernel with the
problem it often stays on a level for loong time, swap disks busy...
and then this happens more and more often and the long times are
getting longer and longer until the swapping no longer stops and
then sooner or later everything else comes to a standstill.

 i hope this helps...
	Juergen