From owner-freebsd-current@FreeBSD.ORG Sun Apr 20 23:22:37 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19D5B37B401; Sun, 20 Apr 2003 23:22:37 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FAA443FBF; Sun, 20 Apr 2003 23:22:36 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.9/8.12.6) with ESMTP id h3L6MYVI092347; Sun, 20 Apr 2003 23:22:34 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9/8.12.6/Submit) id h3L6MYPK092346; Sun, 20 Apr 2003 23:22:34 -0700 (PDT) Date: Sun, 20 Apr 2003 23:22:34 -0700 (PDT) From: Matthew Dillon Message-Id: <200304210622.h3L6MYPK092346@apollo.backplane.com> To: Jeff Roberson References: <20030421013449.V76635-100000@mail.chesapeake.net> cc: David Schultz cc: freebsd-current@freebsd.org Subject: Re: Broken memory management on system with no swap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 06:22:37 -0000 :This is actually analogous to a problem that is solved in the 4bsd :scheduler. The decay is effected by the load average so that all :processes do not reach the highest priority as a result of a heavily :loaded system. The analogous idea being scaling some value based on :current system load. : :What we could do is apply a filter to a raw act count based on memory :pressure. I'm not familiar enough with the properties of the act count in :practice to suggest what that filter should be. I think this should make :the system quite dynamic though. You would require fewer passes for most :cases eh? : :Cheers, :Jeff Well, I don't think that would work as you might expect. Thrashing is a function of memory load which will often have a direct correlation with system load (since blocked processes count in the load calculation). The act_count algorithm greatly reduces and smooths the effect of thrashing. If you cause pages to be held in the active queue for a shorter period of time based on load you would cause thrashing to occur sooner rather then later, pretty much destroying the whole purpose of having act_count in the first place. The degenerate case that might be occuring here is not related to act_count holding a page in the active queue too long, because act_count is ignored if the pageout daemon has to take a second pass. The degenerate case is simply a side effect of the way the pageout daemon's algorithm operates which requires a minimum of two passes to get a page from the active queue to the free/cache queues. I will also note that heavy page laundering is also defered until the second pass (though I think the issue here is unrelated to dirty pages since it has been indicated that 'cp' used write() for the test in question rather then mmap()). Since the second pass is going to happen anyway we need only defer the process killing code till then to (hopefully) solve the problem. -Matt Matthew Dillon