From owner-freebsd-stable@FreeBSD.ORG Mon May 10 20:45:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D5FB1106566B for ; Mon, 10 May 2010 20:45:10 +0000 (UTC) (envelope-from mandrews@bit0.com) Received: from magnum.bit0.com (magnum.bit0.com [207.246.88.226]) by mx1.freebsd.org (Postfix) with ESMTP id AB4E08FC14 for ; Mon, 10 May 2010 20:45:10 +0000 (UTC) Received: from magnum.int.bit0.com (localhost [127.0.0.1]) by magnum.bit0.com (Postfix) with ESMTP id 13655114B1; Mon, 10 May 2010 16:45:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at bit0.com Received: from magnum.bit0.com ([127.0.0.1]) by magnum.int.bit0.com (magnum.int.bit0.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eo0zH5WuSkO; Mon, 10 May 2010 16:45:05 -0400 (EDT) Received: from beast.int.bit0.com (beast.int.bit0.com [172.27.0.2]) by magnum.bit0.com (Postfix) with ESMTP; Mon, 10 May 2010 16:45:05 -0400 (EDT) Date: Mon, 10 May 2010 16:45:05 -0400 (EDT) From: Mike Andrews X-X-Sender: mandrews@beast.int.bit0.com To: Steve Polyack In-Reply-To: <4BE83B9B.5030209@comcast.net> Message-ID: References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <4BE82C5D.1080806@bit0.com> <4BE83B9B.5030209@comcast.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 20:45:10 -0000 On Mon, 10 May 2010, Steve Polyack wrote: > On 05/10/10 11:55, Mike Andrews wrote: >> On 5/5/10 11:19 AM, Freddie Cash wrote: >>> On Tue, May 4, 2010 at 11:32 PM, Giulio Ferro >>> wrote: >>> >>>> Giulio Ferro wrote: >>>> >>>>> Thanks, I'll try these settings. >>>>> >>>>> I'll keep you posted. >>>>> >>>> >>>> Nope, it's happened again... Now I've tried to rise vm.kmem_size to 6G... >>>> I'm really astounded at how unstable zfs is, it's causing me a lot of >>>> problem. >>>> Why isn't it stated in the handbook that zfs isn't up to production yet? >>>> >>> >>> As with everything related to computers, it all depends on your uses. >> >> Sorry to semi-hijack this, but... I'm also running into frequent "kmem_map >> too small" panics on 8-STABLE, such as: >> >> panic: kmem_malloc(131072): kmem_map too small: 2023780352 total allocated >> panic: kmem_malloc(131072): kmem_map too small: 2011525120 total allocated >> panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocated >> panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocated >> panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocated >> panic: kmem_malloc(131072): kmem_map too small: 2020409344 total allocated >> panic: kmem_malloc(536576): kmem_map too small: 2022957056 total allocated >> >> (those are over the course of 3-4 days) >> >> On this specific system, it has 32 GB physical memory and has >> vfs.zfs.arc_max="2G" and vm.kmem_size="64G" in /boot/loader.conf. The >> latter was added per earlier suggestions on this list, but appears to be >> ignored as "sysctl vm.kmem_size" returns about 2 GB (2172452864) anyway. >> >> > As Artem stated in another reply, you will need to set vm.kmem_size slightly > under 2x the physical memory. The kernel will default to 2GB if you pass > this limit. 1.5x physical memory size should be sufficient, so try "48G" and > verify that it gets set correctly on the next boot. OK, I've got vm.kmem_size set a bit lower and it now accepts it. It's still not clear why this just recently (April?) became necessary to do at all :) Meanwhile, I'll see if things get more stable now...