From owner-freebsd-current  Wed Apr 14  6:56: 3 1999
Delivered-To: freebsd-current@freebsd.org
Received: from kot.ne.mediaone.net (kot.ne.mediaone.net [24.218.12.203])
	by hub.freebsd.org (Postfix) with ESMTP id 7C27414FD0
	for <current@freebsd.org>; Wed, 14 Apr 1999 06:56:00 -0700 (PDT)
	(envelope-from mi@kot.ne.mediaone.net)
Received: (from mi@localhost)
	by kot.ne.mediaone.net (8.9.1a/8.9.1) id JAA25377
	for current@freebsd.org; Wed, 14 Apr 1999 09:53:22 -0400 (EDT)
From: Mikhail Teterin <mi@kot.ne.mediaone.net>
Message-Id: <199904141353.JAA25377@kot.ne.mediaone.net>
Subject: Re: swap-related problems
In-Reply-To: <Pine.BSF.4.10.9904140924070.18456-100000@picnic.mat.net> from Chuck Robey at "Apr 14, 1999 09:34:43 am"
To: current@freebsd.org
Date: Wed, 14 Apr 1999 09:53:22 -0400 (EDT)
X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w<gv/&E-lL7twZCT8B~/PA4|\t$ti+22K">
	 hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli"<kcG^EOVih
	 y+z3/UR{6SCQ
X-Mailer: ELM [version 2.4ME+ PL49 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Chuck Robey once stated:

=He's not talking about an artificial limit, he's talking about another
=user making off with all the memory.  This sounds very bizarre, how can
=you possibly ask the system to predict what other user's are going to
=ask for, in advance?  You can't possibly get absolute permissions on
[...]
=These are fundamental design problems (which you have been told already)
=and the way that FreeBSD chooses to act is arguably a very good one.
=There is nothing here that violates any fundamental rules, because we
=are talking about OS wide allocation strategies.  If you need
=guarantees, then you have to buy more memory, more swap, and have less
=hungry users.

All I want is that a program gets NULL from malloc if there is no memory
available. I find that to be a very fundamental thing about malloc.

In response, me and others are told at different times:

	. there is no such thing as "no memory available" (!!!)
	. you can get that behaviour by limiting the user's maximum
	  datasize
	. this wouldn't work without dumping the overcommit strategy,
	  which would demand more memory and will slow things down
	. be a better sysadmin
	. get more memory and swap
	. this discussion is annoying and fruitless (!!!)

I find this responses unacceptable, or only partially acceptable...

	-mi


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message