Messages in this thread |  | | From | "Manfred Spraul" <> | Subject | Re: Purpose of the mm/slab.c changes | Date | Tue, 11 Sep 2001 20:41:32 +0200 |
| |
> I think the cleanup I'm sure you read of this comment in page_alloc.c: * Buddy system. Hairy. You really aren't expected to understand this * * Hint: -mask = 1+~mask
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/
|  |