Re: Purpose of the mm/slab.c changes

[Andrea Arcangeli <andrea@suse.de>]

On Tue, Sep 11, 2001 at 08:41:32PM +0200, Manfred Spraul wrote:
> > 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.

I wouldn't say "not only in such case" but "mainly in such case"
(there's not infinite ram in the per-cpu caches).

> If I can modify my slab allocator to guarantee it, you'd drop your
> patch?

I'm open to an alternate more optimized approch, however I've to say
that using the struct list_head and maintaining the very clean three
separated lists was really nice IMHO.

Also I believe there are more interesting parts to optimize on the
design side rather than making the slab.c implementation more complex
with the object of microoptimization for microbenchmarks (as you told me
you couldn't measure any decrease in performance in real life in a
sendfile benchmark, infact the first run with the patch was a little
faster and the second a little slower).

Andrea