Date: Sun, 11 Nov 2012 06:10:39 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Eitan Adler <eadler@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, Alfred Perlstein <bright@mu.org>, src-committers@FreeBSD.org, Alfred Perlstein <alfred@FreeBSD.org> Subject: Re: svn commit: r242847 - in head/sys: i386/include kern Message-ID: <20121111044336.M891@besplex.bde.org> In-Reply-To: <CAF6rxgmabVuR0JoFURRUF%2Bed0hmT=LF_n5LXSip0ibU0hk6qWw@mail.gmail.com> 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> <509E847E.30509@mu.org> <CAF6rxgnfm4HURYp=O4MY8rB6H1tGiqJ3rdPx0rZ8Swko5mAOZg@mail.gmail.com> <509E8930.50800@mu.org> <CAF6rxgmabVuR0JoFURRUF%2Bed0hmT=LF_n5LXSip0ibU0hk6qWw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 10 Nov 2012, Eitan Adler wrote: > On 10 November 2012 12:04, Alfred Perlstein <bright@mu.org> wrote: >> Sure, if you'd like you can help me craft that comment now? > > I think this is short and clear: > === > Limit the amount of kernel address space used to a fixed cap. > 384 is an arbitrarily chosen value that leaves 270 MB of KVA available > of the 2 MB total. On systems with large amount of memory reduce the > the slope of the function in order to avoiding exhausting KVA. > === The code and the original log message are much clearer. Saying "2MB total" in the above significantly obfuscates the 2MB in the code. As documented in the log message, it is a heuristic scale factor for scaling from the _physical_ memory size to the maxusers parameter. It is also clear in the code that it doesn't scale from a virtual memory size, but less clear that it scales to something related to a virtual memory size (it scales to maxusers which is used to tune parametrize many things including kva, and the 384 is mainly to limit it for the kva things. This is bogus of course). The 2MB is certainly not for kva, and even more certainly, the total kva is not 2MB. "slope of the function" is an unclear way of describing the scaling steps. Originally, there was only the scaling step involving scaling physical memory by 2MB. Scaling was stopped when maxusers hit 384: maxusers was clamped at 384. This corresponds to changing the "slope of the function" to 0. Now we change it to 1/8 of the 1/2MB scale, i.e., to incrementing maxusers by 1 for every 16MB of _physical_ memory. This is still bogus, but probably better than clamping. Describing this is complicated by the new VM_MAX_AUTOTUNE_MAX_USERS parameter. This gives a clamp on maxusers corresponding to the old one of 384 when VM_MAX_AUTOTUNE_MAX_USERS is defined to be that value. This is needed mainly for PAE. I don't like this value being ifdefed. For PAE, the value just can't be increased (except as described below), and decreasing it is not useful. Other unclarities in the above: - its first sentence says that the limit is to a fixed cap, but the whole point of recent changes is to change the limit from a fixed cap to a variable one. The second sentence describes the old behviour with the fixed cap. The third sentence modifies the first 2. > Limit the amount of kernel address space used to a fixed cap. > 384 is an arbitrarily chosen value that leaves 270 MB of KVA available > of the 2 MB total. On systems with large amount of memory reduce the > the slope of the function in order to avoiding exhausting KVA. Original log message: % ---------------------------- % revision 1.51 % date: 2002/01/25 01:54:16; author: dillon; state: Exp; lines: +3 -3 % 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 All these magic numbers are completely wrong if someone changes VM_MIN_KERNEL_ADDRESS, as is very reasonable if they run out of of kva. There is a normal if not working option for this (KVA_PAGES), unlike for VM_MAX_AUTOTUNE_MAX_USERS or the old hard-coded 384. Doubling of the i386 KVA_PAGES from 256 to 512 should approximately double many of the above numbers and more than double others (when the kva consumed by say the buffer cache is not doubled to match, we can have more than double the kva for mbufs. There are other bogus limits and tuning of the buffer cache based on a fixed limit and physical memory, and doubling KVA_PAGES doesn't double all of these). PAE already doubles KVA_SIZE, so all of the above numbers must be off by a factor of about 2 for either PAE or !PAE. The magic numbers are also made significantly wrong by any significant use of the buffer cache limit to increase the amount of kva for the buffer cache. Anyone who does this must know what they are doing, but isn't helped by hard-coded magic number in comments. The above numbers are probably slightly made slightly wrong by general bloat. If 384 gave 270 MB free in 201, it must give < 270 MB in 2012. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121111044336.M891>