From owner-freebsd-arch Sat May 12 10:22: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id EE99837B424 for ; Sat, 12 May 2001 10:21:56 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f4CHLSS18553; Sat, 12 May 2001 10:21:28 -0700 (PDT) (envelope-from dillon) Date: Sat, 12 May 2001 10:21:28 -0700 (PDT) From: Matt Dillon Message-Id: <200105121721.f4CHLSS18553@earth.backplane.com> To: Rik van Riel Cc: arch@freebsd.org, linux-mm@kvack.org, sfkaplan@cs.amherst.edu Subject: Re: on load control / process swapping References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Ahhh, so FreeBSD _does_ have a maxscan equivalent, just one that :only kicks in when the system is under very heavy memory pressure. : :That explains why FreeBSD's thrashing detection code works... ;) : :(I'm not convinced, though, that limiting the speed at which we :scan the active list is a good thing. There are some arguments :in favour of speed limiting, but it mostly seems to come down :to a short-cut to thrashing detection...) Note that there is a big distinction between limiting the page queue scan rate (which we do not do), and sleeping between full scans (which we do). Limiting the page queue scan rate on a page-by-page basis does not scale. Sleeping in between full queue scans (in an extreme case) does scale. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message