Re: [PATCH] per-page SLAB freeing (only dcache for now)

[Marcelo Tosatti <marcelo.tosatti@cyclades.com>]

On Sat, Oct 22, 2005 at 08:16:13PM +0200, Manfred Spraul wrote:
> Christoph Lameter wrote:
> 
> >The current worst case is 16k pagesize (IA64) and one cacheline sized 
> >objects (128 bytes) (hmm.. could even be smaller if the arch does 
> >overrride SLAB_HWCACHE_ALIGN) yielding a maximum of 128 entries per page. 
> >
> > 
> >
> What about biovec-1? On i386 and 2.6.13 from Fedora, it contains 226 
> entries. And revoke_table contains 290 entries.

Neither are reclaimable however, right:

[marcelo@logos linux-2.6.13]$ find . -type f -exec grep -l set_shrinker {} \;
./fs/dcache.c
./fs/dquot.c
./fs/inode.c
./fs/mbcache.c
./fs/xfs/linux-2.6/kmem.h

If the size of the bitmap for caching the slabbufctl data (which
contains dead/alive information) ends up being a problem, its possible
to:

- increase the bitmap size somehow
- drop the bitmap, acquiring the cache's spinlock and checking directly

Or as a last resort drop the slabbufctl optimization completly, using
cache internal information to obtain dead/alive status.



--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>