From owner-freebsd-hackers Sat Sep 29 9:53:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 339ED37B40E for ; Sat, 29 Sep 2001 09:53:36 -0700 (PDT) Received: (from dillon@localhost) by earth.backplane.com (8.11.6/8.11.2) id f8TGrRR37689; Sat, 29 Sep 2001 09:53:27 -0700 (PDT) (envelope-from dillon) Date: Sat, 29 Sep 2001 09:53:27 -0700 (PDT) From: Matt Dillon Message-Id: <200109291653.f8TGrRR37689@earth.backplane.com> To: Wilko Bulte Cc: Alfred Perlstein , Vladimir Dozen , hackers@FreeBSD.ORG Subject: Re: VM: dynamic swap remapping (patch) References: <20010929155941.A291@eix.do-labs.spb.ru> <20010929071024.Q59854@elvis.mu.org> <20010929141349.A80876@freebie.xs4all.nl> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> overcommit? I've always wanted the ability to turn off overcommit :> for exactly the same reasons you do. : :FWIW: Tru64 has had this capability since day one. You can select :swap-overcommit mode by removing a symlink (/sbin/swapdefault -> /dev/foob) :were /dev/foob is the primary swap partition. : :W/ : :-- :| / o / /_ _ email: wilko@FreeBSD.org :|/|/ / / /( (_) Bulte Arnhem, The Netherlands Well, the overcommit argument comes up once or twice a year. Frankly I don't see much of a point to it. While it is true that you could implement a signal the plain fact of the matter is that having to deal with the possibility in a program at the N points (generally hundreds of points) where that program allocates memory, either directly or indirectly, virtually guarentees that you will introduce bugs into the system. You also cannot guarentee that your process will have time to cleanup prior to the system killing, nor can you guarentee that all the standard system utilities and daemons will be able to gracefully handle the out of memory condition. In otherwords, you could implement the signal and even have the program use it, but you will still likely leave gaping holes in the implementation that will result in lost data. It is much easier to manage memory manually. For example, if these programs require 1G of independant memory to run it ought to be a fairly simple matter to simply create a 1GB file for each process (using dd rather then ftruncate() to create the file so the blocks are preallocated), mmap() it using PROT_READ|PROT_WRITE, MAP_SHARED|MAP_NOSYNC, and do your memory management out of that. The memory space will be backed by the file rather then by swap. You get all the benefits of the standard overcommit capabilities of the system as well as the ability to pre-reserve the main workspace for the programs and you automatically get persistent storage for the data. Problem solved. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message