Date: Sat, 29 Sep 2001 09:53:27 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Wilko Bulte <wkb@freebie.xs4all.nl> Cc: Alfred Perlstein <bright@mu.org>, Vladimir Dozen <vladimir-dozen@mail.ru>, hackers@FreeBSD.ORG Subject: Re: VM: dynamic swap remapping (patch) Message-ID: <200109291653.f8TGrRR37689@earth.backplane.com> References: <20010929155941.A291@eix.do-labs.spb.ru> <20010929071024.Q59854@elvis.mu.org> <20010929141349.A80876@freebie.xs4all.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200109291653.f8TGrRR37689>