Date: Sun, 30 Sep 2001 12:59:23 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> 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: <200109301959.f8UJxN544635@earth.backplane.com> References: <909.1001839737@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: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.
-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?200109301959.f8UJxN544635>