From owner-freebsd-stable@FreeBSD.ORG Sat Dec 20 18:05:33 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9322D16A4CE for ; Sat, 20 Dec 2003 18:05:33 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0796643D58 for ; Sat, 20 Dec 2003 18:05:30 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) hBL25KaH005778; Sat, 20 Dec 2003 18:05:20 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id hBL25K5D005777; Sat, 20 Dec 2003 18:05:20 -0800 (PST) (envelope-from dillon) Date: Sat, 20 Dec 2003 18:05:20 -0800 (PST) From: Matthew Dillon Message-Id: <200312210205.hBL25K5D005777@apollo.backplane.com> To: "David G. Lawrence" References: <20031218203355.GC45155@gromit.dlib.vt.edu> <20031220215543.GP213@nexus.dglawrence.com> cc: freebsd-stable@freebsd.org Subject: Re: Problems reclaiming VM cache = XFree86 startup annoyance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2003 02:05:33 -0000 :... :> (Paul Mather) :> As you can probably gather, all this manual intervention is a bit of a :> hassle. So, my question is this: is there a way explicitly to force :> the kernel to flush its VM cache (to move it to "Free"). Failing :> that, are there any sysctls to tune to help alleviate the problem? :> The only sysctls I change in /etc/sysctl.conf are as follows: : :(DG) : I don't know what is causing your problem, but 'cache' pages in FreeBSD :are free pages - they can be allocated directly in the page allocation code. :They only differ from "free" pages in that they contain cached file data. : So the number of pages 'cache' vs. 'free' isn't the cause of the problem. :... Other disk activity can interfere with swap performance. If these other background jobs Paul is running are doing a lot of disk I/O or using a lot of memory, regardless of their nice value, they could be causing a significant reduction in swap I/O performance and/or be causing page thrashing. The 'swwrt' state is waiting for an I/O to complete, *NOT* waiting for a memory allocation, which implies an I/O performance issue. It is likely that nothing is frozen per-say, just that I/O performance is insufficient to handle the paging load caused by starting X *AND* the I/O/memory load of whatever other background processes are running. When you ^Z the background process, the I/O it is performing stops which allows the paging I/O being caused by the X startup to get 100% of available disk bandwidth. Also remember that in an I/O bound situation, the 'nice' value of a process becomes irrelevant because there is plenty of cpu available due to all the processes being predominantly in a blocking state on I/O. The easiest solution is to add more memory to the machine. It is fairly obvious to me that the machine does not have enough for the workload being thrown at it. Alternatively you may wish to examine the memory and I/O footprint of these nice +20 processes and take steps to significantly reduce both. -Matt Matthew Dillon