[patch 1/3] mm: SLUB fix reclaim_state

SLUB does not correctly account reclaim_state.reclaimed_slab, so it will
break memory reclaim. Account it like SLAB does.

Cc: stable@kernel.org
Cc: linux-mm@kvack.org
Cc: Pekka Enberg <redacted>
Cc: Matt Mackall <redacted>
Cc: Christoph Lameter <redacted>
Signed-off-by: Nick Piggin <redacted>
---
 mm/slub.c |    3 +++
 1 file changed, 3 insertions(+)

Index: linux-2.6/mm/slub.c
===================================================================

--- linux-2.6.orig/mm/slub.c
+++ linux-2.6/mm/slub.c

@@ -9,6 +9,7 @@
  */
 
 #include <linux/mm.h>
+#include <linux/swap.h> /* struct reclaim_state */
 #include <linux/module.h>
 #include <linux/bit_spinlock.h>
 #include <linux/interrupt.h>

@@ -1170,6 +1171,8 @@ static void __free_slab(struct kmem_cach
 
 	__ClearPageSlab(page);
 	reset_page_mapcount(page);
+	if (current->reclaim_state)
+		current->reclaim_state->reclaimed_slab += pages;
 	__free_pages(page, order);
 }
 


--

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>

Acked-by: Christoph Lameter <redacted>


--
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>

On Tue, 2009-05-05 at 19:13 +1000, npiggin@suse.de wrote:

plain text document attachment (mm-slub-fix-reclaim_state.patch)
SLUB does not correctly account reclaim_state.reclaimed_slab, so it will
break memory reclaim. Account it like SLAB does.

Cc: stable@kernel.org
Cc: linux-mm@kvack.org
Cc: Pekka Enberg <redacted>
Cc: Matt Mackall <redacted>
Cc: Christoph Lameter <redacted>
Signed-off-by: Nick Piggin <redacted>

I have applied the patch series. I see you have cc'd stable so I assume
you want this in 2.6.30, right? This seems like a rather serious bug but
I wonder why we've gotten away with it for so long? Is there a test
program or a known workload that breaks without this?

			Pekka

--
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>

On Wed, 6 May 2009, Pekka Enberg wrote:

I have applied the patch series. I see you have cc'd stable so I assume
you want this in 2.6.30, right? This seems like a rather serious bug but
I wonder why we've gotten away with it for so long? Is there a test
program or a known workload that breaks without this?

You need to have a load that results in extensive slab reclaim so that the
slab pages in the reclaim path become a factor.

--
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>

On Wed, May 06, 2009 at 10:20:30AM +0300, Pekka Enberg wrote:

On Tue, 2009-05-05 at 19:13 +1000, npiggin@suse.de wrote:

quoted

plain text document attachment (mm-slub-fix-reclaim_state.patch)
SLUB does not correctly account reclaim_state.reclaimed_slab, so it will
break memory reclaim. Account it like SLAB does.

Cc: stable@kernel.org
Cc: linux-mm@kvack.org
Cc: Pekka Enberg <redacted>
Cc: Matt Mackall <redacted>
Cc: Christoph Lameter <redacted>
Signed-off-by: Nick Piggin <redacted>

I have applied the patch series. I see you have cc'd stable so I assume
you want this in 2.6.30, right? This seems like a rather serious bug but

Thanks. I think it makes sense to into 2.6.30. Also probably all active
.stable kernels.

I wonder why we've gotten away with it for so long? Is there a test
program or a known workload that breaks without this?

Well... it isn't doing what reclaim code wants, and it is differing
behaviour between SLAB and SL?B, so I think it is fairly safe to
merge these now.

It doesn't look like too much *significant* changes to heuristics, but
things will get skewed here and there.

--
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>

On Wed, May 06, 2009 at 10:20:30AM +0300, Pekka Enberg wrote:

On Tue, 2009-05-05 at 19:13 +1000, npiggin@suse.de wrote:

quoted

plain text document attachment (mm-slub-fix-reclaim_state.patch)
SLUB does not correctly account reclaim_state.reclaimed_slab, so it will
break memory reclaim. Account it like SLAB does.

Cc: stable@kernel.org
Cc: linux-mm@kvack.org
Cc: Pekka Enberg <redacted>
Cc: Matt Mackall <redacted>
Cc: Christoph Lameter <redacted>
Signed-off-by: Nick Piggin <redacted>

I have applied the patch series. I see you have cc'd stable so I assume
you want this in 2.6.30, right? This seems like a rather serious bug but
I wonder why we've gotten away with it for so long? Is there a test
program or a known workload that breaks without this?

We might overreclaim a bit on the LRU lists, but not that much, as we
scan them in SWAP_CLUSTER_MAX (32 pages) steps only most of the time
and use the same value as a total goal.

So it will rescan the LRU lists if they didn't yield 32 pages, even if
slab cache pruning was more successful.

Only hibernation has a larger scan goal and it will then reclaim the
extra amount of LRU pages that it failed to account for slab pruning,
which might hurt with 15mb worth of reclaimable slab caches.

	Hannes

--
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>

On Wed, May 06, 2009 at 10:20:30AM +0300, Pekka Enberg wrote:

On Tue, 2009-05-05 at 19:13 +1000, npiggin@suse.de wrote:

quoted

plain text document attachment (mm-slub-fix-reclaim_state.patch)
SLUB does not correctly account reclaim_state.reclaimed_slab, so it will
break memory reclaim. Account it like SLAB does.

Cc: stable@kernel.org
Cc: linux-mm@kvack.org
Cc: Pekka Enberg <redacted>
Cc: Matt Mackall <redacted>
Cc: Christoph Lameter <redacted>
Signed-off-by: Nick Piggin <redacted>

I have applied the patch series. I see you have cc'd stable so I assume
you want this in 2.6.30, right? This seems like a rather serious bug but
I wonder why we've gotten away with it for so long? Is there a test
program or a known workload that breaks without this?

Appears to me to be less a correctness than a balancing issue. reclaim
state is a back channel into the shrink code that says 'yes, this is
working'. Without it, things should still work, but possibly not as
smoothly.

-- 
Mathematics is the supreme nostalgia of our time.

--
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>

Hi Nick,

On Wed, 2009-05-06 at 15:42 +0200, Nick Piggin wrote:

quoted

I have applied the patch series. I see you have cc'd stable so I assume
you want this in 2.6.30, right? This seems like a rather serious bug but

Thanks. I think it makes sense to into 2.6.30. Also probably all active
.stable kernels.

quoted

I wonder why we've gotten away with it for so long? Is there a test
program or a known workload that breaks without this?

Well... it isn't doing what reclaim code wants, and it is differing
behaviour between SLAB and SL?B, so I think it is fairly safe to
merge these now.

It doesn't look like too much *significant* changes to heuristics, but
things will get skewed here and there.

Yeah, that's my thinking too. Oh, well, I'll forward it to Linus' way
and let the stable guys decide whether they want to take it or not.

			Pekka

--
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>