From owner-freebsd-chat Thu Apr 15 13:26:53 1999 Delivered-To: freebsd-chat@freebsd.org Received: from mail.webmaster.com (mail.webmaster.com [209.133.28.138]) by hub.freebsd.org (Postfix) with ESMTP id AA60814DBD for ; Thu, 15 Apr 1999 13:26:50 -0700 (PDT) (envelope-from davids@webmaster.com) Received: from whenever ([209.133.29.2]) by mail.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Thu, 15 Apr 1999 13:14:50 -0700 From: "David Schwartz" To: "Daniel C. Sobral" , Cc: , Subject: RE: swap-related problems Date: Thu, 15 Apr 1999 13:24:27 -0700 Message-ID: <000001be877d$f5ddd410$021d85d1@whenever.youwant.to> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <3716476E.80DF2DBC@newsguy.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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