From owner-freebsd-current@FreeBSD.ORG Mon Jan 28 14:23:11 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EC7AE5AC; Mon, 28 Jan 2013 14:23:11 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id AC4C8E0B; Mon, 28 Jan 2013 14:23:10 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r0SENAx7046060; Mon, 28 Jan 2013 07:23:10 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0SEMmAo020875; Mon, 28 Jan 2013 07:22:48 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Trouble with recent auto-tuning changes From: Ian Lepore To: alc@FreeBSD.org In-Reply-To: References: <1359310302.93359.48.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Jan 2013 07:22:48 -0700 Message-ID: <1359382968.93359.66.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Andre Oppermann X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Jan 2013 14:23:12 -0000 On Mon, 2013-01-28 at 00:09 -0600, Alan Cox wrote: > On Sun, Jan 27, 2013 at 12:11 PM, Ian Lepore wrote: > > > I ran into a panic while attempting to un-tar a large file on a > > DreamPlug (arm-based system) running -current. The source and dest of > > the un-tar is the root filesystem on sdcard, and I get this: > > > > panic: kmem_malloc(4096): kmem_map too small: 12582912 total allocated > > > > Just before the panic I see the tar process get hung in a "nokva" wait. > > 12582912 is the value of VM_KMEM_SIZE from arm/include/vmparam.h. > > > > In r245575 the init order for mbuf limits was changed from > > SI_SUB_TUNABLES to SI_SUB_KMEM so that mbuf limits could be based on the > > results of sizing kernel memory. Unfortunately, the process of sizing > > kernel memory relies on the mbuf limits; in kmeminit(): > > > > vm_kmem_size = VM_KMEM_SIZE + nmbclusters * PAGE_SIZE; > > > > Since r245575, nmbclusters is zero when this line of code runs. If I > > manually plugin "32768" (the number tunable_mbinit() comes up with for > > this platform) in that line, the panic stops happening. > > > > So we've got two problems here... one is the circular dependency in > > calculating the mbuf limits. The other is the fact that some > > non-trivial amount of kernel memory we're allowing for mbufs is actually > > being used for other things. That is, if my system was actually using > > all the mbufs that tunable_mbinit() allowed for, then this panic while > > untarring a huge file would still have happened. > > > > > All of this is factually correct. However, it's a red herring. The real > problem is that arm, unlike every other architecture in the tree, does not > enable auto-sizing of the kmem map based on the physical memory size. > Specifically, you'll find VM_KMEM_SIZE_SCALE defined in > "arch"/include/vmparam.h on every other architecture, just not on arm. > This auto-sizing overrides the value of VM_KMEM_SIZE. > Aha. I'll investigate what other architectures do with that and try to get the same thing going for arm. -- Ian > > > > I arrive at the latter conclusion based on the fact that this panic > > happens even if no network interfaces (other than lo0) are configured. > > That is, nmbclusters == 0 is a reasonable approximation of my need for > > network mbufs. So something in the system needs to be taken into > > account when sizing kernel memory to allow for whatever it is about > > untarring a huge file that eats kernel memory (buffer cache?). > > > > I can easily reproduce this if you need me to gather any specific info. > > > > -- Ian > > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >