Date: Thu, 7 Dec 2000 11:52:33 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> 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 Message-ID: <200012071952.eB7JqXm11711@earth.backplane.com> References: <vmsno08u4f.wl@rina.r.dl.itc.u-tokyo.ac.jp> <vmr93k8tqe.wl@rina.r.dl.itc.u-tokyo.ac.jp> <20001207013611.O16205@fw.wintelcom.net> <vmpuj48svm.wl@rina.r.dl.itc.u-tokyo.ac.jp> <20001207015651.P16205@fw.wintelcom.net> <vmofyo8ran.wl@rina.r.dl.itc.u-tokyo.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
:On Thu, 7 Dec 2000 01:56:51 -0800, : Alfred Perlstein <bright@wintelcom.net> 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 <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012071952.eB7JqXm11711>