From owner-svn-src-all@FreeBSD.ORG Sat Nov 10 16:48:33 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6236C39D for ; Sat, 10 Nov 2012 16:48:33 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id B48AE8FC15 for ; Sat, 10 Nov 2012 16:48:32 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so4674030lag.13 for ; Sat, 10 Nov 2012 08:48:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=/2hxDk033V3n1KMXmWHcI0DSbWCX+ZJ0TJ+/fK1rsOs=; b=qOBblqn16SnG72PCaeMU0zn1dautX0nQHck5LtsgTF8OUKtgMo1bdxfSnS/xC48SCa ZsqMA+UH+lGct2Dqjwedui7qZ1YXxcgcb7w7wjSgDr7zK8FiiRK0jP3uucPz4VCRXqBE REHrcc385qcjEl0huK2WOO9mQnx7uZsEi+Dhw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=/2hxDk033V3n1KMXmWHcI0DSbWCX+ZJ0TJ+/fK1rsOs=; b=Yvy4h3PUHz566qeHxZasLIYRt6njcni3+PHoEX8MussCD9cAb72GPOG6B0JQ/OCjii c55VjSfRekWw47f39KifqRkHtlPsbEz8FfT38XfysVxKbNDkRoP/rVqVIYRK/sS6tagW 1KGLB3AWCmkuoNWOTvUBf1ebu+xYyyDD0F4HKISTjmu8gKMsKAtMYxo1nEelIO+6oW3E ioYFx2lI+W9No4hFKZRodGS/8osR9I0s34qjqFa8Y6bS3zBd+PpnKFAAn61aDyb5a6dH saPbKouNf17aqK8wDtbGPwZYV0py44h1FFMV4rElNBwLdnlEejDVAeFHLZC70S3h1+QM fR+Q== Received: by 10.152.104.148 with SMTP id ge20mr13403233lab.51.1352566111431; Sat, 10 Nov 2012 08:48:31 -0800 (PST) MIME-Version: 1.0 Sender: lists@eitanadler.com Received: by 10.112.25.166 with HTTP; Sat, 10 Nov 2012 08:48:01 -0800 (PST) In-Reply-To: <509E847E.30509@mu.org> References: <201211100208.qAA28e0v004842@svn.freebsd.org> <509DC25E.5030306@mu.org> <509E3162.5020702@FreeBSD.org> <509E7E7C.9000104@mu.org> <509E830D.5080006@mu.org> <509E847E.30509@mu.org> From: Eitan Adler Date: Sat, 10 Nov 2012 11:48:01 -0500 X-Google-Sender-Auth: ZxHcub2LoFZKv0HeuZcAPipNfCI Message-ID: Subject: Re: svn commit: r242847 - in head/sys: i386/include kern To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmjKyXgH69l2v6nq4930RjqDaFUrZcr+bvTR2xMlz1IIdTNmY1Nkv0CE1/0NOULgTpAKcI7 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Alfred Perlstein , src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 16:48:33 -0000 On 10 November 2012 11:44, Alfred Perlstein 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 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