Date: Wed, 14 Jul 1999 14:27:19 -0700 From: Jason Thorpe <thorpej@nas.nasa.gov> To: John Baldwin <jobaldwi@vt.edu> Cc: tech-userlevel@netbsd.org, freebsd-hackers@FreeBSD.ORG, Matthew Dillon <dillon@apollo.backplane.com> Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Message-ID: <199907142127.OAA01681@lestat.nas.nasa.gov>
next in thread | raw e-mail | index | archive | help
On Tue, 13 Jul 1999 23:18:58 -0400 (EDT)
John Baldwin <jobaldwi@vt.edu> 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 <thorpej@nas.nasa.gov>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907142127.OAA01681>