From owner-svn-src-head@FreeBSD.ORG Sat Nov 10 17:04:48 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 C97DC8A1; Sat, 10 Nov 2012 17:04:48 +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 A55088FC0A; Sat, 10 Nov 2012 17:04:48 +0000 (UTC) Received: from Alfreds-MacBook-Pro-5.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 5ED2F1A3C1C; Sat, 10 Nov 2012 09:04:48 -0800 (PST) Message-ID: <509E8930.50800@mu.org> Date: Sat, 10 Nov 2012 09:04:48 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eitan Adler 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Alfred Perlstein , src-committers@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 17:04:48 -0000 On 11/10/12 8:48 AM, Eitan Adler wrote: > On 10 November 2012 11:44, Alfred Perlstein wrote: >> On 11/10/12 8:38 AM, Alfred Perlstein wrote: >>> On 11/10/12 8:25 AM, Eitan Adler wrote: >>>> On 10 November 2012 11:19, Alfred Perlstein wrote: >>>>> Please consult the svn log for this file, it's relatively clear just in >>>>> the >>>>> commit logs/comments. Grep for 384/512 and look around. >>>> Can this reasoning be added as a comment? I did grep for 384 in the log, >>>> but >>>> a) I didn't find the answer >>>> b) one shouldn't have to. >>>> >>>> >>> It probably could be added, but then a bunch of other people would >>> complain about the comment being too wordy or "not in English". >>> >>> I will paste the relevant log messages which do explain it. If you would >>> like to add a comment or work on a comment that won't be criticized for >>> being "too wordy" then we can do that together. >>> >>> r89769 | dillon | 2002-01-24 17:54:16 -0800 (Thu, 24 Jan 2002) | 9 lines >>> >>> Make the 'maxusers 0' auto-sizing code slightly more conservative. Change >>> from 1 megabyte of ram per user to 2 megabytes of ram per user, and >>> reduce the cap from 512 to 384. 512 leaves around 240 MB of KVM available >>> while 384 leaves 270 MB of KVM available. Available KVM is important >>> in order to deal with zalloc and kernel malloc area growth. >>> >>> Reviewed by: mckusick >>> MFC: either before 4.5 if re's agree, or after 4.5 >>> >>> >>> r87546 | dillon | 2001-12-08 17:57:09 -0800 (Sat, 08 Dec 2001) | 6 lines >>> >>> Allow maxusers to be specified as 0 in the kernel config, which will >>> cause the system to auto-size to between 32 and 512 depending on the >>> amount of memory. >>> >>> MFC after: 1 week >>> >> Let me add a bit of commentary on these logs... >> >> Effectively what happens is that as "maxusers" goes up, the amount of kernel >> memory needed for the structures grows. Unfortunately at a certain point >> the slope of this function is too steep and makes it too easy to exhaust >> kernel address space (which kills the crab (and the kernel)) what was >> decided at the time was just to cap it hard. > I understand this. What I was confused by is where the number "384" > comes from? Was this empirically tested? Mathematically deduced? > Arbitrarily chosen? > > I think the log messages you pasted mostly answered this. > > Sure, if you'd like you can help me craft that comment now? -alfred