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 <bri...@mu.org> 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.
What was really needed was for the slope to be relaxed and for
architectures to be allowed to override/cap it if needed.
This is now done. Hopefully it's done correctly and will last us some time.
-Alfred
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
