Subject: Re: Has importing the FreeBSD malloc(3) been considered?
To: None <email@example.com>
From: Michael Graff <firstname.lastname@example.org>
Date: 02/22/1999 06:35:13
Zdenek Salvet <email@example.com> writes:
> Have you tried to measure some non-artificial benchmark like "make build" ?
> AFAIK, NetBSD malloc is heavily optimized for small allocations,
> I remeber it had beaten GNUmalloc by large margin when I did tests
> with my malloc-intensive application some time ago.
Running 4 make builds on my laptoy gave:
2:51 (first run of a new build, NetBSD malloc)
2:42 (second run, still NetBSD malloc)
2:48 (first run after adding FreeBSD's malloc to libc)
2:44 (second run, whole system using FreeBSD's malloc now)
I manually ran a "make clean" between each build.
There are two problems with using FreeBSD's malloc:
(1) It uses mmap() which isn't counted against a process's
virtual space. It probably should be, no?
(2) There are a few minor controls that we need to adjust
per-arch. They are pretty clearly indicated near the top
of the file, and seem to be adjustments page allocations
and on minimum allocations. It's just a matter of testing
the malloc on various ports.
There are many benefits:
(1) A memory hungry application of mine (raytracer) will
actually run on my smaller computer now. NetBSD's malloc
is pretty wasteful.
(2) Even while the computer was paging like mad, the overall
feel wasn't severely impacted. Perhaps this was just
luck, and perhaps it was due to other kernel changes, but
the machine _felt_ nice, just slightly sluggish when I
changed what I was doing.
(3) By replacing malloc, we fix a long-standing bug in
NetBSD's malloc, where it seems to throw away a page for
every one allocated. Try a loop of page-size allocations,
and you'll lose 2 pages per malloc() it seems. bind8
added an internal memory allocator to work around just
All in all, I think it's time to replace our malloc with FreeBSD's