From owner-freebsd-hackers Wed Jul 14 14:27:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id A9AC114DC0 for ; Wed, 14 Jul 1999 14:27:29 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id OAA01681; Wed, 14 Jul 1999 14:27:19 -0700 (PDT) Message-Id: <199907142127.OAA01681@lestat.nas.nasa.gov> To: John Baldwin Cc: tech-userlevel@netbsd.org, freebsd-hackers@FreeBSD.ORG, Matthew Dillon Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Reply-To: Jason Thorpe From: Jason Thorpe Date: Wed, 14 Jul 1999 14:27:19 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 23:18:58 -0400 (EDT) John Baldwin wrote: > What does that have to do with overcommit? I student administrate a undergrad > CS lab at a university, and when student's programs misbehaved, they generate a > fault and are killed. The only machines that reboot on us without be > explicitly told to are the NT ones, and yes we run FreeBSD. What does it have to do with overcommit? Everthing in the world! If you have a lot of users, all of which have buggy programs which eat a lot of memory, per-user swap quotas don't necessarily save your butt. And maybe the individual programs didn't encounter their resource limits. ...but the sheer number of these runaway things caused the overcommit to be a problem. If malloc() or whatever had actually returned NULL at the right time (i.e. as backing store was about to become overcommitted), then these runaway processes would have stopped running away (they would have gotten a SIGSEGV and died). Anyhow, my "lame undergrads" example comes from a time when PCs weren't really powerful enough for the job (or something; anyhow, we didn't have any in the department :-). My example is from a Sequent Balance (16 ns32032 processors, 64M RAM [I think; been a while], 4.2BSD variant). -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message