[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Braun/Planeta slab allocator (was: GNU Hurd development blog: 2011-q
Re: Braun/Planeta slab allocator (was: GNU Hurd development blog: 2011-q3)
Thu, 24 Nov 2011 15:20:06 +0100
On Thu, Nov 24, 2011 at 04:02:25PM +0200, Maksym Planeta wrote:
> And thanks, Richard, for mentoring me. You helped me a lot, especially
> with your code style corrections. I'll try to keep all your suggestions.
You're welcome, although I hope I didn't inadvertently make you value
form more than content :-).
> Difference isn't big, but I disagree that it's just a noise, because
> this difference is systematic and constant in some range. At least
> according to tests that I made in September, but your results don't
> disprove it.
Still, people really shouldn't expect any difference in performance. The
pros are really 1/ reduced fragmentation, 2/ clean, maintainable code
and 3/ debugging features (although being smp-ready is nice too). The
slab allocator may probably be *slower* for some workloads because of
the efforts it makes to keep fragmentation low, but as seen while
observing the allocator statistics, the few arbitrary limits still
present, most importantly the hard limit on the maximum number of
objects retained in the page cache, prevent the kernel from having "too
many" allocated objects.
For those interested in getting statistics from a kernel using the slab
allocator, a slabinfo  tool is publically available (although it will
take some time to get it in the Hurd, because of the mach_debug
interface not being exported, I'll open discussion on that soon).