From owner-freebsd-arch Tue May 8 19: 8:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id 4C3C437B423 for ; Tue, 8 May 2001 19:08:34 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id MAA04160; Wed, 9 May 2001 12:07:48 +1000 (EST) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37641) with ESMTP id <01K3CY9R4TGGRX79H5@cim.alcatel.com.au>; Wed, 9 May 2001 12:07:37 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f4927hR25482; Wed, 09 May 2001 12:07:43 +1000 (EST envelope-from jeremyp) Content-return: prohibited Date: Wed, 09 May 2001 12:07:43 +1000 From: Peter Jeremy Subject: Re: on load control / process swapping In-reply-to: <200105090018.f490IGR87881@earth.backplane.com>; from dillon@earth.backplane.com on Tue, May 08, 2001 at 05:18:16PM -0700 To: Matt Dillon Cc: Kirk McKusick , Rik van Riel , arch@FreeBSD.ORG, linux-mm@kvack.org, sfkaplan@cs.amherst.edu Mail-Followup-To: Matt Dillon , Kirk McKusick , Rik van Riel , arch@FreeBSD.ORG, linux-mm@kvack.org, sfkaplan@cs.amherst.edu Message-id: <20010509120743.Y59150@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <200105082052.NAA08757@beastie.mckusick.com> <200105090018.f490IGR87881@earth.backplane.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2001-May-08 17:18:16 -0700, Matt Dillon wrote: > I don't think we want to kick out running processes. Thrashing > by definition means that many of the processes are stuck in > disk-wait, usually from a VM fault, and not running. The other > effect of thrashing is, of course, the the cpu idle time goes way > up due to all the process stalls. A process that is actually able > to run under these circumstances probably has a small run-time footprint > (at least for whatever operation it is currently doing), so it should > definitely be allowed to continue to run. I don't think this follows. A program that does something like: { extern char memory[BIG_NUMBER]; int i; for (i = 0; i < BIG_NUMBER; i += PAGE_SIZE) memory[i]++; } will thrash nicely (assuming BIG_NUMBER is large compared to the currently available physical memory). Occasionally, it will be runnable - at which stage it has a footprint of only two pages, but after executing a couple of instructions, it'll have another page fault. Old pages will remain resident for some time before they age enough to be paged out. If the VM system is stressed, swapping this process out completely would seem to be a win. Whilst this code is artificial, a process managing a very large hash table will have similar behaviour. Given that most (all?) recent CPU's have cheap hi-resolution clocks, would it be worthwhile for the VM system to maintain a per-process page fault rate? (average clock cycles before a process faults). If you ignore spikes due to process initialisation etc, a process that faults very quickly after being given the CPU wants a working set size that is larger than the VM system currently allows. The fault rate would seem to be proportional to the ratio between the wanted WSS and allowed RSS. This would seem to be a useful parameter to help decide which process to swap out - in an ideal world the VM subsystem would swap processes to keep the WSS of all in-core processes at about the size of non-kernel RAM. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message