Date: Sat, 13 Jul 2002 05:22:43 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: David Schultz <dschultz@uclink.Berkeley.EDU> Cc: Peter Wemm <peter@wemm.org>, Matthew Dillon <dillon@apollo.backplane.com>, Sean Kelly <smkelly@zombie.org>, hackers@FreeBSD.ORG Subject: Re: swapoff? Message-ID: <3D301B93.F7CC4F1C@mindspring.com> References: <20020713071911.GA1558@HAL9000.wox.org> <20020713073404.9869A3811@overcee.wemm.org> <20020713115746.GA2162@HAL9000.wox.org>
next in thread | previous in thread | raw e-mail | index | archive | help
David Schultz wrote: > 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.) I like the idea of a moving average on time-from-request-to-service. 8-). Works great for Server Load Balancing, too. The moving average takes load into account, without explicit load notification (i.e. no need to have a load notification protocol between NFS clients and servers, etc.). > 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. 8-). "Now that everyone is talking about it, better get my hacks in first, so that other people have to integrate with my changes, instead of the other way around"... Actually, I think it's a nice idea for an incremental project. -- Terry 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?3D301B93.F7CC4F1C>