From owner-freebsd-arch Thu Dec 7 11:52:49 2000 From owner-freebsd-arch@FreeBSD.ORG Thu Dec 7 11:52:46 2000 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 0625137B401 for ; Thu, 7 Dec 2000 11:52:46 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB7JqXm11711; Thu, 7 Dec 2000 11:52:33 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Dec 2000 11:52:33 -0800 (PST) From: Matt Dillon Message-Id: <200012071952.eB7JqXm11711@earth.backplane.com> To: Seigo Tanimura Cc: bright@wintelcom.net, tanimura@r.dl.itc.u-tokyo.ac.jp, arch@FreeBSD.ORG Subject: Re: Even 1GB KVA is not enough, but we have no more space References: <20001207013611.O16205@fw.wintelcom.net> <20001207015651.P16205@fw.wintelcom.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Thu, 7 Dec 2000 01:56:51 -0800, : Alfred Perlstein said: : :>> >> URI: http://people.FreeBSD.org/~tanimura/patches/vm.diff :>> :Alfred> in the loop you use to allocate, you never test if 'n' hits zero, :Alfred> now if there's a swap problem you won't print anything, just wedge :Alfred> hard. :>> :>> It should also be good to reject swapon(2) if swap_zone is NULL. : :Alfred> Agreed. Since you've been pouring through this code, I'm wondering :Alfred> what happens when the swapper can't allocate as much as it wants? : :Alfred> Does it just reduce the amount of swaping the machine can do? or :Alfred> is there a performance hit? or both? : :Reduction of swap metadata entries primarily results in failure to :allocate a metadata entry, limiting the maximum size of vm objects :that can be used at a time. Another effect is for the pagedaemon to :wait for a free matadata entry, slowing down the speed of swap out. : :-- :Seigo Tanimura Running out of swapmeta may not be an option. A system deadlock could result. The real problem here is that swapmeta is being reserved based on some multiple of main memory rather then based on the actual amount of swap allocated. Another possibility would be to reserve swap in larger chunks... that is, in SWAP_META_PAGES (16-page) chunks rather then page-sized chunks. The struct swblock structure would then turn into a single daddr_t (base swap address) and a bitmap (one int), reducing its size from 80 bytes to 24 bytes. The only problem with this is that the VM object collapse code needs to merge swap areas on a page-by-page basis, so it isn't entirely trivial. Another possibility would be to have some way to swap the swblock structures themselves, relegating the SWAPMETA zone to a cache. Also not trivial. In anycase, your stopgap patch seems reasonable in concept until we can come up with a better solution. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message