From owner-freebsd-hackers Sun Feb 25 3:39:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 4BDB737B401 for ; Sun, 25 Feb 2001 03:39:29 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p36-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.37]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id UAA08841; Sun, 25 Feb 2001 20:39:13 +0900 (JST) Message-ID: <3A98EE37.7B0B6CE0@newsguy.com> Date: Sun, 25 Feb 2001 20:36:23 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: Peter Seebach , freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102241643.f1OGhw616627@guild.plethora.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > > seebs@plethora.net (Peter Seebach) writes: > > Is there any hope that, some day, a setting could be provided where a program > > could request that malloc *NOT* overcommit? There are programs which would > > rather know in advance, and clean up, than be killed abruptly. > > Malloc() does not overcommit - the kernel does. Malloc() doesn't know > and doesn't care. > > I imagine you could add a compile-time option that forces obreak() > (why do we still use brk()/sbrk()?) to prefault the newly allocated > address space. Or you could write a malloc() implementation that only > uses mmap(), and add a flag value that makes mmap() prefault pages, > and fail if there isn't enough memory available. > > None of these solutions are portable, however; the portable way around > memory overcommit is to write a malloc() wrapper that installs a > SIGSEGV handler, then tries to dirty the newly allocated memory, and > fails gracefully if this causes a segfault. Untested code: None of these solutions will work. In all of the above cases, it is still possible for an application to be killed due to out of memory conditions caused by other applications. The main point of non-overcommitting applications is to avoid that. Personally, I like AIX solution of a SIGDANGER signal, and having applications that do not have a handler installed be killed first. But that isn't what is being asked for. OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who *wants* that feature to sit down and code it. It won't happen otherwise. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@kzinti.bsdconspiracy.net Acabou o hipismo-arte. Mas a desculpa brasileira mais ouvida em Sydney e' que nao tem mais cavalo bobo por ai'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message