Re: [patch 3/4] slab reclaim balancing

[Andrew Morton <akpm@digeo.com>]

Manfred Spraul wrote:
> 
> > Slab caches no longer hold onto completely empty pages.  Instead, pages
> > are freed as soon as they have zero objects.  This is possibly a
> > performance hit for slabs which have constructors, but it's doubtful.
> 
> It could be a performance hit for slab with just one object - e.g the
> page sized names cache, used in every syscall that has a path name as a
> parameter.
> 
> Ed, have you benchmarked that there is no noticable slowdown?
> e.g. test the time needed for stat("."). on UP, otherwise the SMP arrays
> would perform the caching.
> 

(What Ed said - we do hang onto one page.  And I _have_ measured
cost in kmem_cache_shrink...)

For those things, the caching should be performed in the page
allocator.  This way, when names_cache requests a cache-hot page,
it may get a page which was very recently a (say) pagetable page,
rather than restricting itself only to pages which used to be
a names_cache page.

CPU caches are per-cpu global.  So the hot pages list should be
per-cpu global also.

Martin Bligh seems to have the patches up and running.  It isn't
very finetuned yet, but initial indications are promising:

Before:
Elapsed: 20.18s User: 192.914s System: 48.292s CPU: 1195.6%

After:
Elapsed: 19.798s User: 191.61s System: 43.322s CPU: 1186.4%

That's for a kernel compile.

And from the profiles, it appears that the benefit is coming
from cache locality, not from the buddylist lock amortisation
which we've also designed into those patches.

I need to stop being slack, and get that code into the pipeline.