Re: [patch 3/4] slab reclaim balancing

[Ed Tomlinson]

On September 26, 2002 05:39 pm, Andrew Morton wrote:
> Manfred Spraul wrote:
> > Andrew Morton wrote:
> > Btw, 140 cycles for kmem_cache_alloc+free is inflated - someone enabled
> > kmem_cache_alloc_head() even in the no-debugging version.
> > As expected, done by Andrea, who neither bothered to cc me, nor actually
> > understood the code.
>
> hm, OK.  Sorry, I did not realise that you were this closely
> interested/involved with slab, so things have been sort of
> going on behind your back :(

Nor did I realize this...  The reasoning behind quickly giving pages back to the 
system was fairly simple.  Previous vm experiements showed that lazy freeing
of pages from the lru was not a good performer.  When the first versions of
slablru went into mm we noticed that large numbers of pages (thousands) were
free but not reclaimed.  This was working as designed - the conclusion was that
slablru was over designed and that lazy removal was probably not such a good
idea.  The slabasap patch that started this thread was the fix for this.

There is no dispute that in some cases it will be slower from a slab perspective.  As
Andrew and you have discussed there are things that can be done to speed things 
up.  Is not the question really, "Are the vm and slab faster together when slab pages 
are freed asap?"

As it stands now we could remove quite a bit of code from slab.  There is no longer
a need for most of the kmem_cache_shrink family, nor is kmem_cache_reap needed
any more.  This simpilifes slab.  If we also enable the per cpu arrays for UP the code
is even cleaner (and hopefully faster).

Manfred, slab is currently using typedefs.  Andrews has stated that he and Linus are
trying to remove these from the kernel.  When I code the cleanup patches for slabasap
(provided it proves itself) shall I clean them out too?

Ed Tomlinson