Re: slab: Remove SLAB_NO_REAP option

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2006-02-23 at 14:18, Pekka Enberg wrote:
On 2/23/06, Alok Kataria <[email protected]> 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 <[email protected]>

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux