Date: Thu, 15 Jul 1999 13:48:40 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: Jason Thorpe <thorpej@nas.nasa.gov> Cc: tech-userlevel@netbsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Message-ID: <378D6828.FCC3C120@newsguy.com> References: <199907142127.OAA01681@lestat.nas.nasa.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
Jason Thorpe wrote: > > 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. The chance of these buggy programs running at the same time is not exactly high... > 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). So, tell me... when NetBSD gets it's non-overcommit switch, would you use it in the environment you describe? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" 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?378D6828.FCC3C120>