Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Apr 1999 13:24:27 -0700
From:      "David Schwartz" <>
To:        "Daniel C. Sobral" <>, <>
Cc:        <>, <chat@FreeBSD.ORG>
Subject:   RE: swap-related problems
Message-ID:  <000001be877d$f5ddd410$>
In-Reply-To: <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

	I'm more interested in solving the general overcommit problem than in the
malloc-specific overcommit problem. As you note, there are ways for a
process to deal with malloc problems. However, the more general
copy-on-write problem and demand load problem are not easily solved without
kernel help.

	As I said, my preferred solution would be a system call that caused all of
a process' demand load or copy-on-write pages (current and future) to be
backed by swap. From that point on, memory failures could only occur at
known failure points, such as malloc or mmap.

> Ok, here is the error of your ways. You are assuming that malloc(3)
> will return memory when there is none. This is incorrect. What
> happens is that processes get killed when the system find itself
> needing more memory than it has available.

	Right. But it's a lot better if malloc returns NULL. That way you don't
lose vital long-running programs. It's really not a good selling point that
an operating system kills off innocent processes when it's low on memory. It
would be a lot nicer if it could simply refuse to allow existing ones to
expand or start new ones.

	However, unfortunately, never overcommitting is a lousy solution.

> There are two ways of preventing that. One is pre-allocate all
> memory. This is not useful, because the memory available to each
> process ends up being very small. As an experiment, run X Free with
> the pre-zero pages flag set.

	Right. It makes sense only to pre-allocate for those processes that really
need it. Then again, swap is cheap. In some cases, it might really make
sense to make all allocations, demand fills, and copy-on-writes backed by
swap system-wide. But again, I hardly think that's a good general solution.

> The second way is to set limits to the memory the processes can use,
> without actually giving up on-demand allocation. FreeBSD supports
> this. Man login.conf(5).

	The problem is, there is no guarantee that I'll be able to use up to my
memory limit. So I don't see how this helps. An overcommit can still result
in a vital process being summarily terminated.


To Unsubscribe: send mail to
with "unsubscribe freebsd-chat" in the body of the message

Want to link to this message? Use this URL: <$f5ddd410$021d85d1>