From owner-freebsd-hackers Sun Sep 30 2:15:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from milliways.chance.ru (milliways.chance.ru [195.190.107.35]) by hub.freebsd.org (Postfix) with ESMTP id 5444E37B40C for ; Sun, 30 Sep 2001 02:15:41 -0700 (PDT) Received: from do-labs.spb.ru (ppp-1.chance.ru [195.190.107.4]) by milliways.chance.ru (8.9.0/8.9.0) with SMTP id NAA02822 for ; Sun, 30 Sep 2001 13:15:37 +0400 (MSD) Received: (qmail 403 invoked by uid 1000); 30 Sep 2001 13:18:40 -0000 Date: Sun, 30 Sep 2001 13:18:40 +0000 From: Vladimir Dozen To: Matt Dillon Cc: Vladimir Dozen , Wilko Bulte , Alfred Perlstein , hackers@FreeBSD.ORG Subject: Re: VM: dynamic swap remapping (patch) Message-ID: <20010930131839.A284@eix.do-labs.spb.ru> References: <20010929155941.A291@eix.do-labs.spb.ru> <20010929071024.Q59854@elvis.mu.org> <20010929141349.A80876@freebie.xs4all.nl> <200109291653.f8TGrRR37689@earth.backplane.com> <20010929232953.B341@eix.do-labs.spb.ru> <200109300752.f8U7qsj41649@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200109300752.f8U7qsj41649@earth.backplane.com>; from dillon@earth.backplane.com on Sun, Sep 30, 2001 at 12:52:54AM -0700 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 ehlo. > : Second, application not always grows to 1G, most of the time it keeps > : as small as 500M ;). Why should we precommit 1G for 500M data? Doing > : multi-mmap memory management is additional pain. > > Why not? Disk space is cheap. Developer time is expensive. Someone already wrote good allocation routines, and they are inside libc. Reinventing bycicle in every new large-scale application doesn't sounds good for me. > For a problem like this I would simply > throw in two 30G+ hard drives and partition them with 16G of swap each, > giving me 32G of swap for the machine. As it was said here before, there are actually two problems: notification (avoiding silently kills) and getting more paging space. The second can be solved by adding swap space. The first -- cannot. As developer, I'm more interested in first. Current solution with killproc() is not acceptable. Just imagine any OS documentation which say: "the OS may terminate process at any point with no warning or notification". Would you like to use it? But this is exactly what FreeBSD does at OOM. > Even using file-backed memory is fairly trivial. You don't need to > do multi-mmap memory management or do any kernel tweaking. Just > reserve 1G and use a single mmap() and file per process. As I already said, it is not trivial. It involves writing/adopting some allocation stuff. It means time & human resources -> money. -- dozen @ home To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message