From owner-freebsd-hackers Mon Jun 2 09:15:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA26188 for hackers-outgoing; Mon, 2 Jun 1997 09:15:05 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA26183 for ; Mon, 2 Jun 1997 09:15:03 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA14593; Mon, 2 Jun 1997 09:09:32 -0700 From: Terry Lambert Message-Id: <199706021609.JAA14593@phaeton.artisoft.com> Subject: Re: LINT and GENERIC - between a rock and a generic place. To: tom@sdf.com (Tom Samplonius) Date: Mon, 2 Jun 1997 09:09:32 -0700 (MST) Cc: terry@lambert.org, jkh@time.cdrom.com, hackers@FreeBSD.ORG In-Reply-To: from "Tom Samplonius" at May 31, 97 05:41:18 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Jordan is speaking to hard limits. The login.conf speaks to soft > > limits, and is still limited to what it can set by the hard limits. > > Well, login.conf does allow you set hard and soft limits, at least in > the language of setrlimit() A hard limit is a limit imposed by system limits. A quota limit is a limit imposed by the system on a particular user. A soft limit or "working set" is the limit imposed on the user by himself, or by his acceptance of less-than-quota-limit defaults for soft limits. It's not my fault that the man pages don't make the distinction so that it's clear that a kernel recompile is needed to raise quota limits above hard limits. Talk to the documentation people. > > The hard limits are the result of static allocations, general at > > initialization time before the kernel is really running, like > > globally declared arrays. > > The only two things I can think of is the maximum number of open files, > and mbufs clusters. > > Why can't these be handled like setting device setttings (IRQs, > baseports, etc)? Boot with a "-c" to change them, before the kernel is > really running, and then write the changes into kernel after boot with > dset. Because they are used as static initializers in the code; the areas are not allocated so much as they are staked out in the kernel data segment via declaration. It is somewhat faster to reference a statically declared area (no pointer dereference). I think the utility outweighs the penalty, however. > > AIX was probably right when it made all this stuff dynamic. Then you > > could at least sysctl the "hard limit" after the machine was up. > > I guess there is performance penalty? Additional pointer dereference per access (as above). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.