From owner-freebsd-current@FreeBSD.ORG Mon Jan 28 06:09:26 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 568E582C; Mon, 28 Jan 2013 06:09:26 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx1.freebsd.org (Postfix) with ESMTP id 53E44AE2; Mon, 28 Jan 2013 06:09:24 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id n8so3431020lbj.31 for ; Sun, 27 Jan 2013 22:09:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uBGja5K34a6x2y2sjajZvAWWZ4YXnpH81Iwd/kG85vo=; b=WQ6eEzdiZNKLHSTYosoA20IzTZo0QVw324+4BjdXlCP56pFMfqHhKd0harEiyj3nza a5dmOtaTqsfPNx50Yw44d44B6n4sxu5liF7MZaERfMRk64Ig/Zn90RWn4q814HcIBm1V No/8/DqLsL3cHNBcTaZByxXyj02jyNAvRVzoVJyYXisx2ernLT+Khbju1oJ7vn1mlSse 7RiPDrj/DThFp1YxAUt1FfgNzfr2i+61tSatzryhMpZrXq7n4pjaft6agVLi22d1097B ikbifGoHadIFK70Y2cRl5yRjwfke5qIfhQL0DLWnpegGiJi8IdA4T96v8nQG7pk7pu0g hwHQ== MIME-Version: 1.0 X-Received: by 10.152.105.17 with SMTP id gi17mr11877132lab.46.1359353357579; Sun, 27 Jan 2013 22:09:17 -0800 (PST) Received: by 10.114.21.197 with HTTP; Sun, 27 Jan 2013 22:09:17 -0800 (PST) In-Reply-To: <1359310302.93359.48.camel@revolution.hippie.lan> References: <1359310302.93359.48.camel@revolution.hippie.lan> Date: Mon, 28 Jan 2013 00:09:17 -0600 Message-ID: Subject: Re: Trouble with recent auto-tuning changes From: Alan Cox To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org, Andre Oppermann X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: alc@freebsd.org 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 06:09:26 -0000 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. > 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" >