From owner-freebsd-current  Wed Apr 14 16:42:31 1999
Delivered-To: freebsd-current@freebsd.org
Received: from misha.cisco.com (misha.cisco.com [171.69.206.50])
	by hub.freebsd.org (Postfix) with ESMTP id AE68214D79
	for <current@freebsd.org>; Wed, 14 Apr 1999 16:42:28 -0700 (PDT)
	(envelope-from mi@misha.cisco.com)
Received: (from mi@localhost)
	by misha.cisco.com (8.9.2/8.9.1) id TAA96857
	for current@freebsd.org; Wed, 14 Apr 1999 19:40:07 -0400 (EDT)
	(envelope-from mi)
From: Mikhail Teterin <mi@misha.cisco.com>
Message-Id: <199904142340.TAA96857@misha.cisco.com>
Subject: Re: swap-related problems
In-Reply-To: <199904142303.QAA43660@troutmask.apl.washington.edu> from Steve Kargl at "Apr 14, 1999 04:03:27 pm"
To: current@freebsd.org
Date: Wed, 14 Apr 1999 19:40:07 -0400 (EDT)
Reply-To: mi@aldan.algebra.com
X-Mailer: ELM [version 2.4ME+ PL52 (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

Steve Kargl once wrote:

> Then, submit your patches to fix the problem preferably with a knob to
> turn your patches on/off. From the discussion, I hope you're prepared
> to deal with the following scenario:
 
I'll be prepared... I don't think it should be a compile time option,
though. May be kernel-compile-time -- malloc isn't really at fault here,
it seems... But rather a run-time.

>   User:    I compiled malloc with -DSTRICT_ANSI.  Now my system appears
>            sluggish and I can't run as many processes because of
>            memory/swap starvation.  
[...]
 
> Submit your patches to the documentation pointing out the alleged
> shortcomings malloc() and friends.

"Alleged" :-)
 
> Meanwhile, visit /usr/ports.

> /usr/ports/devel/libxalloc
> /usr/ports/devel/libmalloc
> /usr/ports/devel/libdlmalloc

I do not see how they can guarantee the usability of the returned
memory with the current kernel. There apparently is no way of
knowing at malloc time if the memory can be used. Worse then that,
it may be possible to use it at malloc time, but unless your program
runs and touches every page, the memory may not be available later.

If we are up to discussing the possible implementations, I'd suggest
that the system uses something other then SIGKILL to notify the
program it's time to pay for the over-commit speed and convenience.
I think, SIGBUS is appropriate, but I'm not sure.

Anything a program can _catch_ and react upon, if its author chooses
to.

Then, one can write a safe malloc, which will install the signal
handler, and touch every page in the the memory referenced by the
to-be-returned pointer. If the signal handler is invoked in the
progress, the to-be-returned memory must be returned back to the
system and NULL should be returned to the caller.

Whether or not to use this "safe" malloc can be determined by malloc
options and/or the size of the request.

However, my (in)ability to propose anything remotely sensible does
not change the facts established in this painful thread. That our
malloc does not conform to standards (for whatever reasons), and
that something should be done about it. That "something" must start
with documenting the flaw...

	-mi


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