Date: Thu, 15 Apr 1999 13:24:27 -0700 From: "David Schwartz" <davids@webmaster.com> To: "Daniel C. Sobral" <dcs@newsguy.com>, <alk@pobox.com> Cc: <chuckr@picnic.mat.net>, <chat@FreeBSD.ORG> Subject: RE: swap-related problems Message-ID: <000001be877d$f5ddd410$021d85d1@whenever.youwant.to> In-Reply-To: <3716476E.80DF2DBC@newsguy.com>
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. DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000001be877d$f5ddd410$021d85d1>