From owner-freebsd-current Tue Aug 27 10:09:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA15509 for current-outgoing; Tue, 27 Aug 1996 10:09:32 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA15504 for ; Tue, 27 Aug 1996 10:09:28 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA24972; Tue, 27 Aug 1996 09:53:42 -0700 From: Terry Lambert Message-Id: <199608271653.JAA24972@phaeton.artisoft.com> Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. To: stesin@gu.kiev.ua Date: Tue, 27 Aug 1996 09:53:42 -0700 (MST) Cc: angio@aros.net, squid-users@nlanr.net, current@FreeBSD.org In-Reply-To: <199608270744.KAA20433@creator.gu.kiev.ua> from "Andrew Stesin" at Aug 27, 96 10:44:12 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > As a result of a pre-2.1.5-release discussion, > I was under impression that libmalloc in FreeBSD-2.1.5 was going > to be a "libPHKmalloc" really, with old libmalloc going elsewhere. > From your message I got an impression that I was wrong. :( > > As for me, I strongly suggest using phkmalloc with Squid > on any platform. Or gnumalloc at least. Default (standard?) > BSD malloc isn't usable. More on this topic... I would like to see the use of an mmap() of /dev/zero replace the use of sbrk() in malloc. For one thing, it would allow us to seperate allocation by thread by establishing sparse allocation zones in the overall process address space. 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. 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. This would resolve the internal heap fragmentation issues of the X server, and of other programs, which do not use a persistance-based locality of allocation model (despite my squawking on the subject, I have only ever seen one persistance-based model implemented without using x86 segment identifiers, and since it was a commercial product, it's unlikely that the code will ever come into common use). Extending the mmap() semantics for page reclaimation also suggests that a "back fill" mechanism will be needed to avoid internal fragmentation (probably not a real problem unless the process normally uses a significant fraction of its available virtual address space). Finally, in the "as long as you're in there" category, it seems that it would be a good idea to support the extension of a mapping region without first unmapping -- a "remmap" in the "realloc" style, if you will. Combining this last with "file size extension" as an FS event to internally cause the mapping to change, at least up to the next page boundry (which has to be mapped anyway because of the VM system's page granularity), should resolve the INN mmap/extension problem. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.