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 [1] 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). -- Richard Braun [1] http://git.sceen.net/rbraun/slabinfo.git/
