Skip site navigation (1)Skip section navigation (2)
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>