From owner-freebsd-current@FreeBSD.ORG Wed Oct 24 15:51:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F749855 for ; Wed, 24 Oct 2012 15:51:41 +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 7221F8FC1C for ; Wed, 24 Oct 2012 15:51:40 +0000 (UTC) Received: (qmail 33676 invoked from network); 24 Oct 2012 17:29:28 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 24 Oct 2012 17:29:28 -0000 Message-ID: <50880EE4.2090502@freebsd.org> Date: Wed, 24 Oct 2012 17:53:08 +0200 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: vadim_nuclight@mail.ru Subject: Re: maxusers (thus mbuf etc.) autotuning capped at 384 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 15:51:41 -0000 On 24.10.2012 16:26, Vadim Goncharov wrote: > Hi, > > We have 'maxusers' tunable which affects many other tunables, e.g. number of > network mbuf/clusters which is often too low on current machines. The mbuf/cluster limit can be rethought as well. Since it all comes out of UMA and is not pre-allocated we could simply set it to "physpages / 2" or "physpages / 4 * 3". Relating it to maxusers isn't meaningful anymore. In the same area the kern.maxfiles, kern.maxfilesperproc and kern.ipc.maxsockets need rethinking as well. For modern systems and busy servers it should be at least in the 100k area, if not more. It should have some magic value per GB physical memory as well. You have to make sure that this is true though: kern.maxfiles > kern.ipc.maxsockets > kern.maxfilesperproc > There is code in sys/kern/subr_param.c: > > if (maxusers == 0) { > maxusers = physpages / (2 * 1024 * 1024 / PAGE_SIZE); > if (maxusers < 32) > maxusers = 32; > if (maxusers > 384) > maxusers = 384; > } > > It was capped to 384 for i386 KVM size limits in r89769, so that amd64, not > constrained to 1Gb KVA, suffers from this. I suspect that 384 may be wrong even > for i386 today, but let's be conservative and limit maxusers to 384 per 1 Gb of > KVM, like this: > > #define _MAX_MAXUSERS (((VM_MAX_KERNEL_ADDRESS - \ > KERNBASE) / (8 * 1024 * 1024)) * 3) > > if (maxusers == 0) { > maxusers = physpages / (2 * 1024 * 1024 / PAGE_SIZE); > if (maxusers < 32) > maxusers = 32; > if (maxusers > _MAX_MAXUSERS) > maxusers = _MAX_MAXUSERS; > } > #undef _MAX_MAXUSERS This is very round-about. Why don't you simply write 384 per GB in there directly? Thinking of it these "magic" whatever-per-GB value definitions should be next to each other in param.h or some other suitable place. -- Andre