Re: slab: Remove SLAB_NO_REAP option

[Alok Kataria <alok.kataria@calsoftinc.com>]

On Thu, 2006-02-23 at 14:18, Pekka Enberg wrote:
On 2/23/06, Alok Kataria <alok.kataria@calsoftinc.com> wrote:
> > There can be some caches which are not used quite often, kmem_cache 
> > for instance. Now from performance perspective having SLAB_NO_REAP for 
> > such caches is good.
>
> Yeah, kmem_cache sounds like a realistic user, but I am wondering if
> it makes any sense for anyone else to use it?
Right, thats why my question still is why do these iscsi & ocfs  cache 
have this flag set.

If we are sure that the flag is still required, we can use the patch 
below.

> If you're not using a
> cache that often, perhaps we're better off using kmalloc() instead?

Right.

Thanks & Regards,
Alok

--
As pointed by Christoph, there is a problem with SLAB_NO_REAP flag. If set 
then the recovery of objects from alien caches is switched off.
Objects not freed on the same node where they were initially
allocated will only be reused if a certain amount of objects
accumulates from one alien node (not very likely) or if the cache is
explicitly shrunk.
This patch facilitates draining of the alien caches irrespective of the value
of SLAB_NO_REAP flag.

Signed-off-by: Alok N Kataria <alok.kataria@calsoftinc.com>

Index: linux-2.6.16-rc4-git5/mm/slab.c
===================================================================
--- linux-2.6.16-rc4-git5.orig/mm/slab.c	2006-02-23 01:09:49.000000000 -0800
+++ linux-2.6.16-rc4-git5/mm/slab.c	2006-02-23 01:12:54.000000000 -0800
@@ -3488,14 +3488,15 @@ static void cache_reap(void *unused)

 		searchp = list_entry(walk, struct kmem_cache, next);

-		if (searchp->flags & SLAB_NO_REAP)
-			goto next;
-
 		check_irq_on();

 		l3 = searchp->nodelists[numa_node_id()];
 		if (l3->alien)
 			drain_alien_cache(searchp, l3->alien);
+
+		if (searchp->flags & SLAB_NO_REAP)
+			goto next;
+
 		spin_lock_irq(&l3->list_lock);

 		drain_array_locked(searchp, cpu_cache_get(searchp), 0,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/