Date: Tue, 27 Aug 1996 12:34:40 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: terry@lambert.org (Terry Lambert) Cc: stesin@gu.kiev.ua, angio@aros.net, squid-users@nlanr.net, current@FreeBSD.org Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. Message-ID: <199608271734.MAA00794@dyson.iquest.net> In-Reply-To: <199608271653.JAA24972@phaeton.artisoft.com> from "Terry Lambert" at Aug 27, 96 09:53:42 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Secondly, the sbrk()-based system recovery of memory assumes too > much allocation locality: the recovery of memory (via sbrk() back > to the system) can only occur at the end of the allocation region. > Actually, we have an madvise(2) in current that supports "freeing" pages, but keeping the VM space. That doesn't do EXACTLY what you say above, but it can help. I have been running with an augmented version of phkmalloc with that change for a long time now. > > I would like to see an extention to the mmap() semantics for sparse > reclaimation on a per-page basis: When a full page is no longer on > use, it would be returned individually to the system. > You can do an munmap that does not correspond directly to an mmap. Also, as I said above, we have an madvise(2) call (arg:MADV_FREE) that releases the page, without giving up the vm space. Specifically, the page is marked clean, and might/might-not be demand-zeroed the next time that you use it. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608271734.MAA00794>