On 10 November 2012 11:44, Alfred Perlstein <bri...@mu.org> wrote: > 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.
I understand this. What I was confused by is where the number "384" comes from? Was this empirically tested? Mathematically deduced? Arbitrarily chosen? I think the log messages you pasted mostly answered this. -- Eitan Adler Source, Ports, Doc committer Bugmeister, Ports Security teams _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
