From owner-cvs-all Thu Jan 31 10:51:57 2002 Delivered-To: cvs-all@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 58AC137B404; Thu, 31 Jan 2002 10:51:49 -0800 (PST) Received: (from dillon@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g0VIpne43133; Thu, 31 Jan 2002 10:51:49 -0800 (PST) (envelope-from dillon) Message-Id: <200201311851.g0VIpne43133@freefall.freebsd.org> From: Matt Dillon Date: Thu, 31 Jan 2002 10:51:49 -0800 (PST) To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/kern vfs_subr.c X-FreeBSD-CVS-Branch: RELENG_4 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG dillon 2002/01/31 10:51:48 PST Modified files: (Branch: RELENG_4) sys/kern vfs_subr.c Log: MFC new vlrureclaim trigger-point code. vlrureclaim()'s purpose in life is to maintain kern.maxvnodes, not to try to free memory. In fact, the reclaim code is generally called when there is lots of memory available but the system has too many vnodes. So we can safely skip vnodes which still have a large number of resident pages present and thereby avoid unnecessary flushes (e.g. for Yahoo, potentially nasty flushes of MAP_NOSYNC pages). We calculate a resident count that guarentees we will still be able to locate enough vnodes to reclaim to satisfy kern.maxvnodes. MFC new vlruvp() procedure, which is currently a NOP. We will be able to utilize this procedure after we've cleaned up the filesystem SYNCing code. Right now SYNC becomes wildly inefficient if the vlruvp() code is enabled. Revision Changes Path 1.249.2.24 +44 -0 src/sys/kern/vfs_subr.c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message