From owner-freebsd-hackers Sat Jul 13 4:59: 3 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D51CD37B400 for ; Sat, 13 Jul 2002 04:59:00 -0700 (PDT) Received: from HAL9000.wox.org (12-233-156-170.client.attbi.com [12.233.156.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EB3843E4A for ; Sat, 13 Jul 2002 04:58:51 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.wox.org (localhost [127.0.0.1]) by HAL9000.wox.org (8.12.3/8.12.3) with ESMTP id g6DBvrf3005005; Sat, 13 Jul 2002 04:57:53 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.wox.org (8.12.3/8.12.3/Submit) id g6DBvlGH005004; Sat, 13 Jul 2002 04:57:47 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Sat, 13 Jul 2002 04:57:46 -0700 From: David Schultz To: Peter Wemm Cc: Matthew Dillon , Sean Kelly , hackers@FreeBSD.ORG Subject: Re: swapoff? Message-ID: <20020713115746.GA2162@HAL9000.wox.org> Mail-Followup-To: Peter Wemm , Matthew Dillon , Sean Kelly , hackers@FreeBSD.ORG References: <20020713071911.GA1558@HAL9000.wox.org> <20020713073404.9869A3811@overcee.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020713073404.9869A3811@overcee.wemm.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Peter Wemm : > One system I used to use years and years ago seperated this process into > stages. The swap(1M) command could be used to enable, disable and 'weight' > allocation to swap areas. The add was easy. 'delete' would cause the > device to be attempted to be paged in, but if the system looked like it was > going to run out of resources it would fail and stop right there. You could > either turn allocation back on, or kill processes or wait for the pager catch > up with moving stuff out to other swap spaces. When (if) it finally hit > zero inuse, it would be deleted. > > It did manage multiple swap spaces as seperate entities with different fill > levels etc [rather than one giant logical swap area], so doing it this way > kinda made sense. I did actually use it once and it even worked. :-) > (I cannibalized my /tmp file system and used it for swap for a project, and > then turned it off and re-mkfs'ed it) The weight idea is very interesting. NetBSD does this using priorities; all the swap devices of a given priority are filled round robin before devices of lower priority, the idea being that the slower ones are a last resort (e.g. NFS). On the other hand, this design allows large and fast swap devices to start swapping to death before the `backup' devices see any action. It isn't clear to me whether priorities or "fill levels" are better. (Certainly a hybrid is possible, that is, weights within priority levels.) This may be a better project for me than swapoff in the immediate future because I won't have to understand how to track down the appropriate VM objects and handle them in a kosher manner. Implementing weights/priorities will also involve dynamically allocating struct swdevt's, which should be done anyway and will only be harder after swapoff() is written. BTW, I believe the comment about swfree() in vm_swap.c is outdated as of rev. 1.17, and nothing uses SW_FREED anymore. This means that technically, swap devices don't have any flags right now, but that could change with swapoff(). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message