From owner-freebsd-hackers Sun Sep 30 12:59:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id CC46137B40B for ; Sun, 30 Sep 2001 12:59:37 -0700 (PDT) Received: (from dillon@localhost) by earth.backplane.com (8.11.6/8.11.2) id f8UJxN544635; Sun, 30 Sep 2001 12:59:23 -0700 (PDT) (envelope-from dillon) Date: Sun, 30 Sep 2001 12:59:23 -0700 (PDT) From: Matt Dillon Message-Id: <200109301959.f8UJxN544635@earth.backplane.com> To: Poul-Henning Kamp Cc: Vladimir Dozen , Wilko Bulte , Alfred Perlstein , hackers@FreeBSD.ORG Subject: Re: VM: dynamic swap remapping (patch) References: <909.1001839737@critter> 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 : :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