Date: Sat, 13 Jul 2002 04:57:46 -0700 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Peter Wemm <peter@wemm.org> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Sean Kelly <smkelly@zombie.org>, hackers@FreeBSD.ORG Subject: Re: swapoff? Message-ID: <20020713115746.GA2162@HAL9000.wox.org> In-Reply-To: <20020713073404.9869A3811@overcee.wemm.org> References: <20020713071911.GA1558@HAL9000.wox.org> <20020713073404.9869A3811@overcee.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Peter Wemm <peter@wemm.org>: > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020713115746.GA2162>