From owner-freebsd-current@FreeBSD.ORG  Wed Jan 23 00:54:03 2013
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 EA68356A
 for <freebsd-current@freebsd.org>; Wed, 23 Jan 2013 00:54:03 +0000 (UTC)
 (envelope-from mcdouga9@egr.msu.edu)
Received: from mail.egr.msu.edu (dauterive.egr.msu.edu [35.9.37.168])
 by mx1.freebsd.org (Postfix) with ESMTP id ADEE9F5B
 for <freebsd-current@freebsd.org>; Wed, 23 Jan 2013 00:54:03 +0000 (UTC)
Received: from dauterive (localhost [127.0.0.1])
 by mail.egr.msu.edu (Postfix) with ESMTP id 9B5E226A5A
 for <freebsd-current@freebsd.org>; Tue, 22 Jan 2013 19:54:02 -0500 (EST)
X-Virus-Scanned: amavisd-new at egr.msu.edu
Received: from mail.egr.msu.edu ([127.0.0.1])
 by dauterive (dauterive.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id R7UDyNuyyjxv for <freebsd-current@freebsd.org>;
 Tue, 22 Jan 2013 19:54:02 -0500 (EST)
Received: from EGR authenticated sender
Message-ID: <50FF34AC.9000204@egr.msu.edu>
Date: Tue, 22 Jan 2013 19:54:04 -0500
From: Adam McDougall <mcdouga9@egr.msu.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: freebsd-current@freebsd.org
Subject: Re: kmem_map auto-sizing and size dependencies
References: <50F96A67.9080203@freebsd.org>
 <CAMBSHm-xPo7bH556h4QwtHhCUHX+4g_pv3=t29C1SLD4VnBWsQ@mail.gmail.com>
 <20130121210645.GC1341@garage.freebsd.pl>
 <CAFqOu6jO1iMM=gS5-x+_91JfCF3zdLW-Dfnvja2QozDWUV+kTA@mail.gmail.com>
In-Reply-To: <CAFqOu6jO1iMM=gS5-x+_91JfCF3zdLW-Dfnvja2QozDWUV+kTA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
 <freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>, 
 <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
 <mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jan 2013 00:54:04 -0000

On 1/22/2013 6:22 PM, Artem Belevich wrote:
> On Mon, Jan 21, 2013 at 1:06 PM, Pawel Jakub Dawidek <pjd@freebsd.org> wrote:
>> On Fri, Jan 18, 2013 at 08:26:04AM -0800, mdf@FreeBSD.org wrote:
>>>>   Should it be set to a larger initial value based on min(physical,KVM) space
>>>>   available?
>>> It needs to be smaller than the physical space, [...]
>> Or larger, as the address space can get fragmented and you might not be
>> able to allocate memory even if you have physical pages available.
> +1 for relaxing upper limit.
>
> I routinely patch all my systems that use ZFS to allow kmem_map size
> to be larger than physical memory. Otherwise on a system where most of
> RAM goes towards ZFS ARC I used to eventually run into dreaded
> kmem_map too small panic.
>
> --Artem
> _______________________________________________
Ever since related code has been patched to properly permit kmem=2x physmem
out of the box, I've been using that guideline for my systems and
I've not had an out of kmem panic in years.  I've previously ran into weird
temporary deadlocks with strong IO if I set the kmem too high, as if the ARC
caused something important to be overwritten; that is just my theory.  I 
agree
with the fragmentation principle here.  YMMV regarding the kmem size.