From owner-svn-src-all@FreeBSD.ORG Sat Nov 10 19:32:27 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 05864262; Sat, 10 Nov 2012 19:32:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id 861A78FC08; Sat, 10 Nov 2012 19:32:25 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qAAJWCc8020875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Nov 2012 06:32:13 +1100 Date: Sun, 11 Nov 2012 06:32:12 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Peter Wemm Subject: Re: svn commit: r242847 - in head/sys: i386/include kern In-Reply-To: Message-ID: <20121111061517.H1208@besplex.bde.org> References: <201211100208.qAA28e0v004842@svn.freebsd.org> <509DC25E.5030306@mu.org> <509E3162.5020702@FreeBSD.org> <509E7E7C.9000104@mu.org> <509E830D.5080006@mu.org> <1352568275.17290.85.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-Cloudmark-Score: 0 X-Optus-Cloudmark-Analysis: v=2.0 cv=JdTkNj2V c=1 sm=1 a=yyKEtvhfh8wA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=aSzTme4LXwMA:10 a=vGqK-bROAAAA:8 a=2lI9rghLtlvfURV_4KEA:9 a=CjuIK1q_8ugA:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 Cc: Ian Lepore , Alfred Perlstein , Eitan Adler , svn-src-all@FreeBSD.org, Alfred Perlstein , src-committers@FreeBSD.org, 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 19:32:27 -0000 On Sat, 10 Nov 2012, Peter Wemm wrote: > On Sat, Nov 10, 2012 at 9:24 AM, Ian Lepore > wrote: >> On Sat, 2012-11-10 at 08:38 -0800, Alfred Perlstein wrote: >>> It probably could be added, but then a bunch of other people would >>> complain about the comment being too wordy or "not in English". >> >> The fact that such a thing could happen explains much about the current >> state of the code. An outsider could easily come to the conclusion that >> the FreeBSD motto is something along the lines of "It should be as hard >> to read as it was to write." > > Don't forget to explain that you get 1 maxusers per 2MB of physical > memory which turns into 64 x 2k clusters and a whole series of side > effects. > > Wouldn't it be nice if we could write "By default, mbuf clusters are > capped at 6% of physical ram or 6% of kernel address space, whichever > is smaller" ? > > That's a little easier than trying to explain > maxusers = physpages / (2 * 1024 * 1024 / PAGE_SIZE) > if (maxusers > 384) > maxusers = 384 + ((maxusers - 384) / 8); > nmbclusters = 1024 + maxusers * 64; > > I'd sure prefer to explain: > > /* pick smaller of kva pages or physical pages */ > if ((physpages / 16) < (kvapages / 16)) > nmbclusters = physpages / 16; > else > nmbclusters = kvapages / 16; > > Leave maxusers for calculating maxproc. I prefer to write clear code and not echo it in comments: nmbclusters = min(physpages, kvapages) / 16; The most interesting point (the reason why 6% was chosen) is not documented by either. Unfortunately, this is too simple to work - probably min() has a wrong type. - probably physical == virtual limit is too simple - varies scaling errors for the magic 16. It assumes that the cluster size is the page size. Your comment avoids this problem by saying "mbuf clusters" and not giving their units, so that is correct if the units are the same as for the memory sizes. But don't ask alfred to fix all the old mistakes. To change to the above, you at least have to subtract the contribution of nmbclusters to maxusers and change related magic and check that everything fits again. Lots of separate limits risks unduly restricting each while not actually preventing over-commit unless all the limits are unduly restrictive. Bruce