From owner-freebsd-stable Thu May 9 17:17:14 2002 Delivered-To: freebsd-stable@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 6894D37B403 for ; Thu, 9 May 2002 17:17:05 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.9.1) with ESMTP id g4A0H3hU029617; Thu, 9 May 2002 17:17:03 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g4A0H3iS029616; Thu, 9 May 2002 17:17:03 -0700 (PDT) Date: Thu, 9 May 2002 17:17:03 -0700 (PDT) From: Matthew Dillon Message-Id: <200205100017.g4A0H3iS029616@apollo.backplane.com> To: Ian Cc: freebsd-stable Subject: Re: Steadily increasing memory usage on a lightly loaded server References: Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Hrm. On a reread of the design discussion, I notice "nor does it move pages :between the various page queues gratuitously when the memory subsystem is :not being stressed." Does this imply that much of of the memory on the :inactive queue would be on the cache queue, but there was no need to waste :cycles moving them to another queue because there was no demand for them? :It strikes me as counter-intuitive that a queue of pages that are "dirty but :not recently referenced" would also hold pages that are no longer owned by a :process (and thus not really dirty). : :-- Ian Correct. The reason we do not try to keep the queues balanced under light memory loads is simply because its a waste of cpu to do so. There is a classic tradeoff at work here: A simple VM system can manage pages very efficiently and thus keep things 'balanced' at all times, but at the cost of not choosing the correct pages to clean or to free when load occurs. A complex VM system can choose the correct page to clean or to free but it costs considerably more cpu to keep the page queues 'balanced'. *Our* VM system is a complex VM system Ultimately the cost of a disk I/O is horrendous compared to the cost of a few cpu cycles, so it makes sense to trade cpu for disk I/O whenever possible. But that doesn't mean we can't choose the right page and eat our cake too! FreeBSD accomplishes this by not trying to keep the queues balanced in situations where there is no need to, thus saving cpu cycles. Under heavier memory loads FreeBSD spends the cpu cycles required to more carefully maintain the page queues because the tradeoff is advantageous during those times. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message