From owner-freebsd-current@FreeBSD.ORG Mon Sep 24 10:07:27 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E73B16A418; Mon, 24 Sep 2007 10:07:27 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id C57DB13C465; Mon, 24 Sep 2007 10:07:25 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46F78C59.1020801@FreeBSD.org> Date: Mon, 24 Sep 2007 12:07:21 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Ruslan Ermilov References: <20070921102946.T11189@borg> <46F415BF.9010500@FreeBSD.org> <20070921140550.D96923@thebighonker.lerctr.org> <46F41CFF.6080108@FreeBSD.org> <46F58799.1030702@freebsd.org> <46F58B21.8030307@FreeBSD.org> <20070924091558.GB32006@team.vega.ru> In-Reply-To: <20070924091558.GB32006@team.vega.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Darren Reed , freebsd-current@FreeBSD.org, Larry Rosenman Subject: Re: panic: kmem_malloc(131072): kmem_map too small (AMD64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2007 10:07:27 -0000 Ruslan Ermilov wrote: > On Sat, Sep 22, 2007 at 11:37:37PM +0200, Kris Kennaway wrote: >> Darren Reed wrote: >>> Kris Kennaway wrote: >>>> Larry Rosenman wrote: >>>>> On Fri, 21 Sep 2007, Kris Kennaway wrote: >>>>> >>>>>> Larry Rosenman wrote: >>>>>>> I'm a heavy ZFS user, and got the following panic on 2007-09-18 >>>>>>> source/world: >>>>>> This is a FAQ, please see the archives (you need to increase the >>>>>> vm.kmem_size to provide more memory to ZFS). >>>>> I thought that was only for i386, and it hadn't been an issue before. >>>> Nope. It is also load-dependent. >>> So I just received this courtesy of ZFS: >>> panic: kmem_malloc(131072): kmem_map too small: 343027712 total allocated >>> cpuid = 0 >>> KDB: enter: panic >>> This was with these settings in loader.conf: >>> vm.kmem_size=419430400 >>> vm.kmem_size_max=419430400 > > Setting both doesn't make sense; kmem_size will take over. > kmem_size_max only limits the automatically computed value > of kmem_size, which is: > > /* > * How many physical pages per KVA page allocated. > * min(max(max(VM_KMEM_SIZE, Physical memory/VM_KMEM_SIZE_SCALE), > * VM_KMEM_SIZE_MIN), VM_KMEM_SIZE_MAX) > * is the total KVA space allocated for kmem_map. > */ > >>> vfs.zfs.arc_max=409715200 >>> (That's 400M, 400M and 40M, respectively.) >>> Stupid question, perhaps, but is vm.kmem_size/vm.kmem_size_max limited by >>> physical RAM? >> Yes. >> > To be precise, it's actually limited by 2 * sizeof(physical RAM). > It's still size of a _virtual_ memory map (kmem_map), after all: > > : /* > : * Limit kmem virtual size to twice the physical memory. > : * This allows for kmem map sparseness, but limits the size > : * to something sane. Be careful to not overflow the 32bit > : * ints while doing the check. > : */ > : if (((vm_kmem_size / 2) / PAGE_SIZE) > cnt.v_page_count) > : vm_kmem_size = 2 * cnt.v_page_count * PAGE_SIZE; Well OK, but that seems pretty dangerous, because it leaves open a pathway to exhaust all of physical memory and presumably panic. Kris