From owner-freebsd-current@FreeBSD.ORG Mon Sep 24 19:04: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 7BDE416A475; Mon, 24 Sep 2007 19:04: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 71EAD13C478; Mon, 24 Sep 2007 19:04:25 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46F80A39.3050707@FreeBSD.org> Date: Mon, 24 Sep 2007 21:04:25 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Scott Long 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> <46F78C59.1020801@FreeBSD.org> <20070924080347.O84223@thebighonker.lerctr.org> <20070924144210.GA82735@team.vega.ru> <46F7D7A4.5090007@samsco.org> In-Reply-To: <46F7D7A4.5090007@samsco.org> 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 19:04:27 -0000 Scott Long wrote: > Ruslan Ermilov wrote: >> On Mon, Sep 24, 2007 at 08:04:33AM -0500, Larry Rosenman wrote: >>> On Mon, 24 Sep 2007, Kris Kennaway wrote: >>> >>>> Ruslan Ermilov wrote: >>>>> On Sat, Sep 22, 2007 at 11:37:37PM +0200, Kris Kennaway wrote: >>>>>> Darren Reed wrote: >> [...] >>>>>>> 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. >>> is KVA pageable? Is the kmem_map dedicating non-pageable memory? >>> >> kmem_map is used to map memory for the zone allocator, including >> malloc(9). >> >>> I've set my vm.kmem_max to 1G, (on a 4G amd64 box). Is that reasonable? >>> >> It just means that your kernel can "malloc" up to 1G of memory. >> > > You're all missing the point, I hate to say. What happened is that a > change was made recently to more accurately account for allocated > memory. Now people are getting kmem_map_too_small panics that weren't > getting them before. So while the accounting is now more accurate, the > outcome is actually harmful. That needs to be fixed before the release. Well yes, that is one hypothesis, but the evidence points elsewhere as well. Prior the change you reference, some of my zfs machines would run for weeks before hitting a load pattern that exhausted their kmem_map and triggered the panic. Also unless I have missed it I am not seeing the sudden flood of panic reports that may indicate sudden breakage. It is quite possible that this particular report has nothing to do with the recent change. Kris