From owner-freebsd-hackers@FreeBSD.ORG  Wed Dec 12 06:20:48 2012
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
 by hub.freebsd.org (Postfix) with ESMTP id 5C0EEBB;
 Wed, 12 Dec 2012 06:20:48 +0000 (UTC) (envelope-from bright@mu.org)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
 by mx1.freebsd.org (Postfix) with ESMTP id E8C568FC12;
 Wed, 12 Dec 2012 06:20:47 +0000 (UTC)
Received: from Alfreds-MacBook-Pro-6.local
 (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218])
 by elvis.mu.org (Postfix) with ESMTPSA id 4E5441A3C3D;
 Tue, 11 Dec 2012 22:20:41 -0800 (PST)
Message-ID: <50C82238.80008@mu.org>
Date: Tue, 11 Dec 2012 22:20:40 -0800
From: Alfred Perlstein <bright@mu.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: hackers@freebsd.org, Eitan Adler <eadler@FreeBSD.org>
Subject: why is kern.maxproc not read/write?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Content-Filtered-By: Mailman/MimeDel 2.1.14
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Dec 2012 06:20:48 -0000

Eitan was asking me to update the FAQ section 5.7:

> *5.7.* Why do I get the error "kernel: proc: table is full"?
>
That error is no longer relevant, but I also seemed to find out 
something else interesting..

Been grepping through the code, and it seems like the only side-effect 
of maxproc changing would be overcrowding the hash table tidhashtbl and 
pidhashtbl.

I can't see anything that's statically allocated any longer.

The only bad thing is that the procs seem to be taken from a 
UMA_ZONE_NOFREE zone, so if the user makes an insanely high value, it 
could be end of days.

Even the MD code seems to use it to size the number of pv entries.

I'm wondering if making this a runtime tunable that has a SYSCTL_PROC 
attached that doesn't allow it to go below some PROC_MIN would be OK.

Am I missing something?

As far as Eitan's question about the FAQ section, the new message 
printed is:
"maxproc limit exceeded by uid %i, please see tuning(7) and login.conf(5)"

The faq is wrong, and tells the user to change sysctl.conf, where it 
should say to update loader.conf.

-Alfred