From owner-svn-src-all@FreeBSD.ORG Sat Nov 10 23:05:01 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB3538EA for ; Sat, 10 Nov 2012 23:05:01 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0AE478FC12 for ; Sat, 10 Nov 2012 23:05:00 +0000 (UTC) Received: (qmail 80643 invoked from network); 11 Nov 2012 00:39:40 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Nov 2012 00:39:40 -0000 Message-ID: <509EDD93.3020001@freebsd.org> Date: Sun, 11 Nov 2012 00:04:51 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Alfred Perlstein Subject: Re: svn commit: r242847 - in head/sys: i386/include kern 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> In-Reply-To: <509ED439.8090607@mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 23:05:01 -0000 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. >> >> Yes, that would be optimal. >> > No it would not. > > I used to be able to tell people "hey just try increasing maxusers" and they would and suddenly the > box would be OK. > > Now I'll have to remember 3,4,5,10,20x tunable to increase? 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. Other than that there is no relation to maxusers except historic behavior. 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. -- Andre > The concept of a single knob to do ***basic*** tuning is a good one. > > Please leave it alone. > > There is nothing about "maxusers" that stops someone from tuning individual subsystems. > > You just wind up making FreeBSD an "experts only" playground by gratuitously changing this. > > Again, please leave it alone, we need basic tuning to be simple and easy. > > What we have now works. Do not pull it apart and make it convoluted and "expert only". > > thank you, > > -Alfred > >