Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Apr 1999 05:43:24 +0900
From:      "Daniel C. Sobral" <>
To:        David Schwartz <>
Cc:        chat@FreeBSD.ORG
Subject:   Re: swap-related problems
Message-ID:  <>
References:  <000001be877d$f5ddd410$>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
David Schwartz wrote:
> > 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.

One could get tired of saying this again and again, but I'm not at
that point yet. :-)

No, it doesn't make sense. Ok, you pre-allocate for some processes.
The memory get filled. Then one of the processes using allocation on
demand needs more memory. But there is no free memory, so a process
gets killed.

You are back where you started. Pre-allocation only works if you do
it for all processes. And if you do that... Well, run the experiment
I mentioned above.

> > 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.

Eh? What are talking about? No garantee?

See, you have this process that you wants to eat as much memory as
possible. If you are not pre-allocating for all processes, you will
have to know which process is that. Knowing that, you set a memory
limit that leaves you with enough memory to run the rest of the

Now, this is a limit you *must* find for any solution you try,
*except* pre-allocating everything. If you are not pre-allocating
everything, you'll have to know how much memory you can use before
processes get killed. 

For example, suppose one uses the "solution" you mention above.
Memory gets filled, and then some other process might need more
memory, and something get killed. There is no way around this. If
you think there is a way around it, think again. If you still think
so, try to explain, in details. It is unavoidable.

Now, we know processes will get killed. So, next, you want to be
able to tell which processes must not get killed. Well, things will
get killed as long as memory is needed. So, you need to be running
processes for the express purpose of them getting killed, freeing
memory so the system can run without anything getting killed.

Surprise, what you did is figure out how much free memory is needed
for the system to run without anything getting killed. This is
equivalent of figuring out how much memory to limit a process to.

If you won't/can't find how much memory each process/user can safely
use, your only solution is to pre-allocate everything.

Daniel C. Sobral			(8-DCS)

	"Well, Windows works, using a loose definition of 'works'..."

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

Want to link to this message? Use this URL: <>