Date: Sat, 09 Dec 2000 14:24:06 +0900 From: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> To: dillon@earth.backplane.com Cc: tanimura@r.dl.itc.u-tokyo.ac.jp, bright@wintelcom.net, arch@FreeBSD.ORG Subject: Re: Even 1GB KVA is not enough, but we have no more space Message-ID: <86elzi88w9.wl@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> In-Reply-To: In your message of "Thu, 7 Dec 2000 11:52:33 -0800 (PST)" <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> <200012071952.eB7JqXm11711@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Dec 2000 11:52:33 -0800 (PST), Matt Dillon <dillon@earth.backplane.com> said: Matt> In anycase, your stopgap patch seems reasonable in concept until we Matt> can come up with a better solution. And the saga continues. After regulating the size of struct swblock, ffs_vget() failed to allocalte a new vnode. At the time the PowerEdge failed, the kernel held around 197K vnodes, which is as large as 46MB. This time I reduced the size of kmem_map, the pool of malloc(9). Although we reserve at most 200MB + mbufs + mbuf clusters for kmem_map, most of the space is not likely to be in use. For example, the bottom line of vmstat -m on the PowerEdge said that only 32MB out of 200MB was used by malloc(9). Counting the actual usage, 100MB should be enough for the malloc(9) pool. Since malloc(9) always wire down allocated pages, you should allocate memory by malloc(9) only if the size of memory to allocate is constant; otherwise you would always have to consider how much wirable pages a user has. Hence it makes no sense to simply scale up the malloc(9) pool size only to waste free entries in kmem_map unreusable. Memory for the device driver framework is a good example of malloc(9) usage because we are not likely to scale up the number of cards on a motherboard in 5, 10 or 20 years. Scaling up is something more than just scaling up parameters. If you see a ceiling, you have to watch out your head. -- Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@FreeBSD.org> 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?86elzi88w9.wl>