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?"