Date: Tue, 29 Nov 2005 20:14:00 +0100 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Jason Evans <jasone@canonware.com> Cc: Maxim.Sobolev@portaone.com, current@FreeBSD.ORG Subject: Re: New libc malloc patch Message-ID: <3340.1133291640@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 29 Nov 2005 08:55:13 PST." <1A7D4B98-9474-42B6-8A21-4C9AB8582EC1@canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <1A7D4B98-9474-42B6-8A21-4C9AB8582EC1@canonware.com>, Jason Evans wr ites: >[...] phkmalloc did an excellent job in this capacity >for quite some time, but now that we need to commonly support >threaded programs on SMP systems, phkmalloc is being strained rather >badly. This isn't an indication that we need multiple malloc >implementations in the base OS; rather it indicates that the system >malloc implementation needs to take into account constraints that did >not exist when phkmalloc was designed. The malloc phkmalloc replaced was written at some point in the 1980ies on a VAX, and more or less assumed the Vax was effectively a single user machine and without effective paging algorithms. Phkmalloc was written in 1994/5 where I had 4MB of RAM in my "Gateway Handbook 486" and very strongly assumed that with the RAM prices of the day, I could not afford an upgrade. I gave a talk about phkmalloc at USENIX ATC 1998 in New Orleans. One of the central points in the talk was that infrastructure code should have regular service overhauls, to check that the assumptions in the design is still valid. In addition to assumptions phkmalloc makes which are no longer relevant, there are many assumptions which should be made today which phkmalloc is not aware of, multi-threading being but one of them. Cache line effects, pipeline prefetching, multi-cpu systems, different VM system algorithms, larger address spaces etc etc etc. Once Jason is done, I have no doubts that "jemalloc" will beat phkalloc in all relevant benchmarking thereby neatly rendering any discussion about having multiple mallocs in the tree pointless. A big thank you from the author of phkmalloc to Jason for following the service manual to the letter :-) Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3340.1133291640>