Re: slablru for 2.5.32-mm1

[Andrew Morton <akpm@zip.com.au>]

Ed Tomlinson wrote:
> 
> ...
> I thought about doing something like your patch.  I wanted to avoid
> semi-magic numbers (why a page worth of objects?  why not two or
> three...).

Well, it's just an efficiency heuristic...

>  I would rather see something like my patch, maybe coded
> in a more stylish way, used.  If we want to get bigger batch I would
> move the kmem_do_prunes up into try_to_free_pages.  This way the
> code is simpler, vmscan changes for slablru are smaller, and nothing
> magic is involved.

Doesn't make much difference, afaict.   Generally, the first pass
through shrink_caches() frees a sufficient number of pages, so
the before- and after- code are equivalent.

And because there is only one flag, we still attempt to prune all
caches which have a pruner, when it's quite possible that just one
of them has a decent amount of stuff.  Probably a minor issue though.

I wouldn't be too fussed about the extent of changes in vmscan.c.
One day, when the kernel is perfect, all of that file will have the
inlines turned on and the whole of page reclaim becomes one big
function.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/