Subject: Re: kernel mem allocator, was: Interface detach branch available
To: None <hauke@Espresso.Rhein-Neckar.DE, email@example.com>
From: Ross Harvey <firstname.lastname@example.org>
Date: 12/16/1998 21:14:23
> From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
> At 8:46 Uhr +0100 16.12.1998, Todd Whitesel wrote:
> >> kernel malloc operates on buckets of size power-of-two. each page is
> >> subdivided into buckets. they're never subdivided.
> >BTW Does anyone know how popular this algorithm is among the various unices?
AFAIK it is used by *BSD and by Digital Unix.
To address the prevously (unquoted) question on fragmentation: it's been
shown to have about 50% fragmentation overhead on at least one benchmark.
(For those of you who are horrified at this, it's actually pretty good,
heap allocators can easily have 100% steady-state footprint overheads.)
Now, pool allocators are much faster...
> Hum. Hasn't NetBSD recently switched to an allocator similar to Solaris' slab?
> (see Vahalia: Unix Internals, p.381 vs. p.392)
Paul Kranenburg did write pool(9) recently, and Jason Thorpe has been switching
internal things over to it one by one.
A quick look at the code shows it to be doing a lot of the same things as the
Solaris slab allocator, including, e.g., cache coloring offsets...