From owner-freebsd-stable@FreeBSD.ORG Mon May 10 20:53:47 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 4C0C2106566B for ; Mon, 10 May 2010 20:53:47 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 19D998FC08 for ; Mon, 10 May 2010 20:53:47 +0000 (UTC) Received: by pxi20 with SMTP id 20so1985549pxi.13 for ; Mon, 10 May 2010 13:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=3VizkY9PtQH6qEZyvb7l6uNLGIhQm43rQmB0Qz5XzGs=; b=i74doXgZRSRARx+jJDKCWapHdeOh8FykwoTF65OSnYby5jsb9tS23wyWt/2MuY/euN 6VZqlBTja25NXJifxQRqZ2XfTvGK+hkhGS72LR7JFPQWGmTp4lFXd0Nj/u6H+AC2pk8M o0pHbIiUzPF511FpioU8nQA+oMGZKyGpQ6SV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=vnlk9V7jx+aDDCI0N42KhPRNYKp5oo8Z/eAOaQjmYFZQ1zA6kDw+33Y6Mz5dwdFNU+ 9qgSwdLnymZgvm83X73ckfJnxdBrcIxGWkYgvU0hcQuGYuSfAD1w+eUY7v3x2UHUYWT+ U5mUPA2f/viFE9BweHzB9FuZNZ+Lg4IKRzebM= MIME-Version: 1.0 Received: by 10.140.58.5 with SMTP id g5mr3079095rva.157.1273524826579; Mon, 10 May 2010 13:53:46 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.141.40.4 with HTTP; Mon, 10 May 2010 13:53:46 -0700 (PDT) In-Reply-To: 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> Date: Mon, 10 May 2010 13:53:46 -0700 X-Google-Sender-Auth: 9e70efb62066c102 Message-ID: From: Artem Belevich To: Mike Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, Steve Polyack 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:53:47 -0000 vm.kmem_size limitation has been this way for a pretty long time. What's changed recently is that ZFS ARC now uses UMA for its memory allocations. If I understand it correctly, this would make ARC's memory use more efficient as allocated chunks will end up in a zone tuned for allocations of particular size. Increased fragmentation could be the side effect of this change, but I'm guessing here. --Artem On Mon, May 10, 2010 at 1:45 PM, Mike Andrews wrote: > 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... =A0I'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=3D"2G" and vm.kmem_size=3D"64G" in /boot/loader.conf. = =A0The >>> latter was added per earlier suggestions on this list, but appears to b= e >>> 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. =A0The kernel will default to 2GB= if >> you pass this limit. =A01.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. =A0It'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... > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >