Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 30 Sep 2001 15:06:26 -0500
From:      Alfred Perlstein <bright@mu.org>
To:        Matt Dillon <dillon@earth.backplane.com>
Cc:        Poul-Henning Kamp <phk@critter.freebsd.dk>, Vladimir Dozen <vladimir-dozen@mail.ru>, Wilko Bulte <wkb@freebie.xs4all.nl>, hackers@FreeBSD.ORG
Subject:   Re: VM: dynamic swap remapping (patch)
Message-ID:  <20010930150626.N59854@elvis.mu.org>
In-Reply-To: <200109301959.f8UJxN544635@earth.backplane.com>; from dillon@earth.backplane.com on Sun, Sep 30, 2001 at 12:59:23PM -0700
References:  <909.1001839737@critter> <200109301959.f8UJxN544635@earth.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
* Matt Dillon <dillon@earth.backplane.com> [010930 14:59] wrote:
> 
> :
> :In message <200109300752.f8U7qsj41649@earth.backplane.com>, Matt Dillon writes:
> :>:  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.
> :>
> :>    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.
> :
> :I once had a patch to phkmalloc() which backed all malloc'ed VM with
> :hidden files in the users homedir.  It was written to put the VM
> :usage under QUOTA control, but it had many useful side effects as well.
> :
> :I can't seem to find it right now, but it is trivial to do: just
> :replace the sbrk(2) with mmap().  Only downside is the needed 
> :filedescriptor which some shells don't like.
> :
> :-- 
> :Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> :phk@FreeBSD.ORG         | TCP/IP since RFC 956
> 
>     I think the file descriptor problem can be solved easily... simply
>     open the file, mmap() the entire 1G segment for this special application,
>     and then close() the file.  Then have sbrk() just eats out of the mapped 
>     segment.  Alternatively sbrk() could open/mmap/close in large 1MB or 4MB
>     segments, again leaving no file descriptors dangling.

Won't that cause fragmentation?  You're forgettng the need to 
ftruncate or pre-zero the file unless that's been fixed.

-- 
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'

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?20010930150626.N59854>