and the slab allocator must sustain more 10 times more allocations/sec:
from lse netbench on sourceforge, 4-cpu, ext2, one minute:
4 million kmallocs,
5 million kmem_cache_alloc
721 000 rmqueue
slab.c doesn't need to be simple, it must be fast.
> and the potential for lifo in the free slabs is much more
> sensible than the other factors you mentioned, of course there's less
> probability of having to fall into the free slabs rather than in the
> partial ones during allocations, but that doesn't mean that cannot
> happen very often, but I will glady suggest to remove it if you prove
> me wrong.
Ok, so you agree that your changes are only beneficial in one case:
kmem_cache_free(), uniprocessor or SMP not-per-cpu cached.
* frees one object
* after that free-operation no further slabs with allocated objects are
left - only full and free slabs.
Your code ensures that the next object returned will be the previously
freed object, my code doesn't guarantee that.
If I can modify my slab allocator to guarantee it, you'd drop your
patch?
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/