Date: Sat, 10 Nov 2012 22:22:52 -0800 From: Peter Wemm <peter@wemm.org> To: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r242847 - in head/sys: i386/include kern Message-ID: <CAGE5yCpExfeJHeUuO0FEEFMgeNzftaFSWT=D-yKGdP%2B1xnjZ4A@mail.gmail.com> In-Reply-To: <20121111061517.H1208@besplex.bde.org> References: <201211100208.qAA28e0v004842@svn.freebsd.org> <CAF6rxg=HPmQS1T-LFsZ=DuKEqH30iJFpkz%2BJGhLr4OBL8nohjg@mail.gmail.com> <509DC25E.5030306@mu.org> <509E3162.5020702@FreeBSD.org> <509E7E7C.9000104@mu.org> <CAF6rxgmV8dx-gsQceQKuMQEsJ%2BGkExcKYxEvQ3kY%2B5_nSjvA3w@mail.gmail.com> <509E830D.5080006@mu.org> <1352568275.17290.85.camel@revolution.hippie.lan> <CAGE5yCp4N7fML05-Tomm0TM-ROBSka5%2Bb9EKJTFR%2ByUpFuGj5Q@mail.gmail.com> <20121111061517.H1208@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 10, 2012 at 11:32 AM, Bruce Evans <brde@optusnet.com.au> wrote: > On Sat, 10 Nov 2012, Peter Wemm wrote: > >> On Sat, Nov 10, 2012 at 9:24 AM, Ian Lepore >> <freebsd@damnhippie.dyndns.org> 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. The divide by 16 was based on observation of existing behavior, notwithstanding my confusion over the point that the slope change kicks in. nmbclusters = 1024 + maxusers * 64; Aside from the elevated starting point, that is 64 x 2K clusters per maxuser bogo-unit. Before the slope change, 2MB ram gives 1 maxuser bogo-unit, which gives 128K of clusters. 2M / 128K = 16, or 6.25%. After the slope change, 16MB ram gives 1 maxuser bogo-unit. 16M / 128k = 128.. or 0.78%. ie: current autoconfiguration is roughly 6% of ram below 768MB, and less than 1% of ram above 768MB. Given that the allocator has changed significantly over the last few years and is a cap now, not a fixed reservation, we should be setting these limits to a comfortable safe limit. Back when it was a fixed reservation we had far more in the way of constraints. Telling people "increase maxusers 10x" is silly. "maxusers" sets two things directly. maxproc and nmbclusers. maxproc = maxusers * 16. Having people increase maxproc as a side effect of trying to increase network buffers is not helpful. Having people do post-defaults tuning in understandable units is much more likely to give predictable results. Which is easier? Q: "How do I get an extra 2MB of clusters?" A1: "increase kern.ipc.nmbclusters by 1000" A2: "well, 2MB is 1000 clusters, and since you have mode than 768M of ram, you divide that 1000 clusters by 16 to get 62, then multiply that by 8 to reverse the maxusers slope factor above 768M, so you need to find the maxusers value you have and add 496 to it. That will probably increase your clusters by 2MB. Maybe." We've had kern.ipc.nmbclusters for years. It is simple to understand, easy to predict the outcome of a change, is runtime adjustable, is a *cap* and not a reservation (like it used to be) and does not require a reboot like maxusers tweaking would, and doesn't change maxproc as a side effect. Tune the caps sensibly by default and move on. maxusers must die. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGE5yCpExfeJHeUuO0FEEFMgeNzftaFSWT=D-yKGdP%2B1xnjZ4A>