From owner-svn-src-head@FreeBSD.ORG Sat Nov 10 23:21:19 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4506BEA; Sat, 10 Nov 2012 23:21:18 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6AD708FC08; Sat, 10 Nov 2012 23:21:18 +0000 (UTC) Received: from [10.0.1.17] (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 1F0D11A3C1F; Sat, 10 Nov 2012 15:21:18 -0800 (PST) References: <201211100208.qAA28e0v004842@svn.freebsd.org> <509DC25E.5030306@mu.org> <509E3162.5020702@FreeBSD.org> <509E7E7C.9000104@mu.org> <509E830D.5080006@mu.org> <509E847E.30509@mu.org> <509E8930.50800@mu.org> <509EA869.6030407@freebsd.org> <509ED439.8090607@mu.org> <509EDD93.3020001@freebsd.org> In-Reply-To: <509EDD93.3020001@freebsd.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <17959D7E-4F3C-4513-91F2-3CDDE3A0D41A@mu.org> X-Mailer: iPhone Mail (9B206) From: Alfred Perlstein Subject: Re: svn commit: r242847 - in head/sys: i386/include kern Date: Sat, 10 Nov 2012 15:21:14 -0800 To: Andre Oppermann Cc: "src-committers@freebsd.org" , Eitan Adler , Peter Wemm , "svn-src-all@freebsd.org" , Alfred Perlstein , "svn-src-head@freebsd.org" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 23:21:19 -0000 On Nov 10, 2012, at 3:04 PM, Andre Oppermann wrote: > On 10.11.2012 23:24, Alfred Perlstein wrote: >> On 11/10/12 11:18 AM, Andre Oppermann wrote: >>> On 10.11.2012 19:04, Peter Wemm wrote: >>>> This is complicated but we need a simple user visible view of it. It >>>> really needs to be something like "nmbclusters defaults to 6% of >>>> physical ram, with machine dependent limits". The MD limits are bad >>>> enough, and using bogo-units like "maxusers" just makes it worse. >>>=20 >>> Yes, that would be optimal. >>>=20 >> No it would not. >>=20 >> I used to be able to tell people "hey just try increasing maxusers" and t= hey would and suddenly the >> box would be OK. >>=20 >> Now I'll have to remember 3,4,5,10,20x tunable to increase? >=20 > No. The whole mbuf and cluster stuff isn't allocated or reserved > at boot time. We simply need a limit to prevent it from exhausting > all available kvm / physical memory whichever is less. >=20 > Other than that there is no relation to maxusers except historic > behavior. >=20 > So the ideal mbuf limit is just short of keeling the kernel over > no matter what maxusers says. There also isn't much to tune then > as the only fix would be to add more physical ram. I think that makes sense. If you have ideas please look into it.=20 -Alfred