Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 30 Sep 2001 13:18:40 +0000
From:      Vladimir Dozen <vladimir-dozen@mail.ru>
To:        Matt Dillon <dillon@earth.backplane.com>
Cc:        Vladimir Dozen <vladimir-dozen@mail.ru>, Wilko Bulte <wkb@freebie.xs4all.nl>, Alfred Perlstein <bright@mu.org>, hackers@FreeBSD.ORG
Subject:   Re: VM: dynamic swap remapping (patch)
Message-ID:  <20010930131839.A284@eix.do-labs.spb.ru>
In-Reply-To: <200109300752.f8U7qsj41649@earth.backplane.com>; from dillon@earth.backplane.com on Sun, Sep 30, 2001 at 12:52:54AM -0700
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010930131839.A284>