From owner-freebsd-arch Fri Dec 8 21:25:19 2000 From owner-freebsd-arch@FreeBSD.ORG Fri Dec 8 21:25:17 2000 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (rina.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id 07CAA37B400 for ; Fri, 8 Dec 2000 21:25:17 -0800 (PST) Received: (from uucp@localhost) by rina.r.dl.itc.u-tokyo.ac.jp (8.11.1+3.4Wpre/3.7W-rina.r-0.1-11.01.2000) with UUCP id eB95PES21947; Sat, 9 Dec 2000 14:25:14 +0900 (JST) Received: from silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (8.11.1+3.4Wpre/3.7W) with ESMTP id eB95O6t42800; Sat, 9 Dec 2000 14:24:07 +0900 (JST) Date: Sat, 09 Dec 2000 14:24:06 +0900 Message-ID: <86elzi88w9.wl@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> From: Seigo Tanimura 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 In-Reply-To: In your message of "Thu, 7 Dec 2000 11:52:33 -0800 (PST)" <200012071952.eB7JqXm11711@earth.backplane.com> References: <20001207013611.O16205@fw.wintelcom.net> <20001207015651.P16205@fw.wintelcom.net> <200012071952.eB7JqXm11711@earth.backplane.com> User-Agent: Wanderlust/1.1.1 (Purple Rain) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 12) (Channel Islands) (i386--freebsd) Organization: Carrots MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 7 Dec 2000 11:52:33 -0800 (PST), Matt Dillon 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message