Re: [PATCH]: Option to run cache reap in thread mode

[Andrew Morton]

Dimitri Sivanich <sivanich@xxxxxxx> wrote:
>
> On Wed, Jun 16, 2004 at 08:58:58PM +0200, Manfred Spraul wrote:
>  > Could you try to reduce them? Something like (as root)
>  > 
>  > # cd /proc
>  > # cat slabinfo | gawk '{printf("echo \"%s %d %d %d\" > 
>  > /proc/slabinfo\n", $1,$9,4,2);}' | bash
>  > 
>  > If this doesn't help then perhaps the timer should run more frequently 
>  > and scan only a part of the list of slab caches.
> 
>  I tried the modification you suggested and it had little effect.  On a 4 cpu
>  (otherwise idle) system I saw the characteristic 30+ usec interruptions
>  (holdoffs) every 2 seconds.

Against which slab cache?  How many objects are being reaped in a single
timer tick?

It's very simple:

--- 25/mm/slab.c~a	2004-06-17 21:38:57.728796976 -0700
+++ 25-akpm/mm/slab.c	2004-06-17 21:40:06.294373424 -0700
@@ -2690,6 +2690,7 @@ static void drain_array_locked(kmem_cach
 static inline void cache_reap (void)
 {
 	struct list_head *walk;
+	static int max;
 
 #if DEBUG
 	BUG_ON(!in_interrupt());
@@ -2731,6 +2732,11 @@ static inline void cache_reap (void)
 		}
 
 		tofree = (searchp->free_limit+5*searchp->num-1)/(5*searchp->num);
+		if (tofree > max) {
+			max = tofree;
+			printk("%s: reap %d\n", searchp->name, tofree);
+		}
+
 		do {
 			p = list3_data(searchp)->slabs_free.next;
 			if (p == &(list3_data(searchp)->slabs_free))
_

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