From owner-svn-src-head@FreeBSD.ORG Thu Nov 8 10:11:33 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 9FEF5A29 for ; Thu, 8 Nov 2012 10:11:33 +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 E87698FC18 for ; Thu, 8 Nov 2012 10:11:31 +0000 (UTC) Received: (qmail 64155 invoked from network); 8 Nov 2012 11:46:38 -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 ; 8 Nov 2012 11:46:38 -0000 Message-ID: <509B854D.9020301@freebsd.org> Date: Thu, 08 Nov 2012 11:11:25 +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: Peter Wemm Subject: Re: svn commit: r242029 - head/sys/kern References: <201210250146.q9P1kLi8043704@svn.freebsd.org> <20121025080551.GG35915@deviant.kiev.zoral.com.ua> <201210250950.57161.jhb@freebsd.org> <509B501F.5050109@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alfred Perlstein , John Baldwin , svn-src-all@freebsd.org, Alfred Perlstein , svn-src-head@freebsd.org, src-committers@freebsd.org, Konstantin Belousov 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: Thu, 08 Nov 2012 10:11:33 -0000 On 08.11.2012 08:46, Peter Wemm wrote: > On Wed, Nov 7, 2012 at 10:24 PM, Alfred Perlstein wrote: >> [[ + peter ]] >> >> Folks, I spent quite a bit of time trying to figure out how to resolve >> maxusers scaling in a happy way for all. >> >> I think I came up with a solution. >> >> This solution should work for i386, and other 32 bit platforms, as well as >> scaling well for 64 bit (or higher) platforms that have virtually unlimited >> AND 64bit with limited kernel address space. >> >> Here is how it works: >> >> We calculate the maxusers value based on physical memory, and then clamp it >> down if physical memory exceeds kernel addressable memory. >> >> The algorithm actually remains the same for all architectures, with the >> exception that machines with large kernel address space it is no longer >> clamped at 384. >> >> I've attached a test program that lets you play with various values for >> VM_MIN_KERNEL_ADDRESS, VM_MAX_KERNEL_ADDRESS and physpages. (argv[1, 2, 3] >> respectively.) >> >> Please give me your feedback. > > This is still bogus. VM_MIN_KERNEL_ADDRESS and VM_MAX_KERNEL_ADDRESS > have no bearing on how much space should be allocated for mbuf > clusters on amd64. If anything, you want dmapbase / dmapend if you > want a practical cap for amd64. Even then, jumbo clusters are >4K so > they come out of kva rather than direct map. > > maxusers is the wrong thing for this. maxusers should, if anything, > be used to set things like kern.maxproc. Preferably it should be > deleted entirely and sysctl.conf should be used to change > kern.maxproc. > > Setting limits for the mbuf / cluster pool should be a MD parameter. > > Trying to scale maxusers based on physical ram in order to get mbuf > cluster limits set as a side effect is just plain wrong. > > It makes no more sense than trying to set nmbclusters based on > PRINTF_BUFR_SIZE, and then trying to scale PRINTF_BUFR_SIZE in order > to get desirable second and third order side effects. > > Scale nmbclusters based on physical ram, with a MD method for capping > it for when there are MD limits (eg: disproportionately small kva on > an i386 PAE machine). Don't use maxusers. ACK -- Andre