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)
d...@newsguy.com
d...@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 majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
