Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))
To: Jason Thorpe <email@example.com>
From: Daniel C. Sobral <firstname.lastname@example.org>
Date: 07/15/1999 13:48:40
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
> 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)
"Would you like to go out with me?"
"I'd love to."
"Oh, well, n... err... would you?... ahh... huh... what do I do