linux-kernel - Re: [patch 1/3] slub: add per-cache slab thrash ratio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.0903300128100.26320@chino.kir.corp.google.com>
Date:	Mon, 30 Mar 2009 01:41:54 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Pekka Enberg <penberg@...helsinki.fi>
cc:	Christoph Lameter <cl@...ux-foundation.org>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Martin Bligh <mbligh@...gle.com>, linux-kernel@...r.kernel.org,
	Mel Gorman <mel@....ul.ie>
Subject: Re: [patch 1/3] slub: add per-cache slab thrash ratio

On Mon, 30 Mar 2009, Pekka Enberg wrote:

> > The slab_thrash_ratio for each cache do not have non-zero defaults
> > (yet?).
> 
> If we're going to merge this code, I think it would be better to put a
> non-zero default there; otherwise we won't be able to hit potential
> performance regressions or bugs. Furthermore, the optimization is not
> very useful on large scale if people need to enable it themselves.
> 
> Maybe stick 20 there and run tbench, sysbench, et al to see if it makes
> a difference? I'm cc'ing Mel in case he has some suggestions how to test
> it.
> 

It won't cause a regression if sane SLAB_THRASHING_THRESHOLD and 
slab_thrash_ratio values are set since the contention on list_lock will 
always be slower than utilizing a more free cpu slab when its thrashing.

I agree that there should be a default value and I was originally going 
to propose the following as the fourth patch in the series, but I wanted 
to generate commentary on the approach first and there's always a 
hesitation when changing the default behavior of the entire allocator for 
workloads with very specific behavior that trigger this type of problem.

The fact that we need a tunable for this is unfortunate, but there doesn't 
seem to be any other way to detect such situations and adjust the partial 
list handling so that list_lock isn't contended so much and the allocation 
slowpath to fastpath ratio isn't so high.

I'd be interested to hear other people's approaches.
---
diff --git a/mm/slub.c b/mm/slub.c
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -147,6 +147,12 @@
  */
 #define SLAB_THRASHING_THRESHOLD 3
 
+/*
+ * Default slab thrash ratio, used to define when a slab is thrashing for a
+ * particular cpu.
+ */
+#define DEFAULT_SLAB_THRASH_RATIO 20
+
 #define DEBUG_DEFAULT_FLAGS (SLAB_DEBUG_FREE | SLAB_RED_ZONE | \
 				SLAB_POISON | SLAB_STORE_USER)
 
@@ -2392,7 +2398,14 @@ static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags,
 	 */
 	set_min_partial(s, ilog2(s->size));
 	s->refcount = 1;
-	s->min_free_watermark = 0;
+	s->min_free_watermark = oo_objects(s->oo) *
+					DEFAULT_SLAB_THRASH_RATIO / 100;
+	/*
+	 * It doesn't make sense to define a slab as thrashing if its threshold
+	 * is fewer than 4 objects.
+	 */
+	if (s->min_free_watermark < 4)
+		s->min_free_watermark = 0;
 #ifdef CONFIG_NUMA
 	s->remote_node_defrag_ratio = 1000;
 #endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/