All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] slub: Avoid direct compaction if possible
@ 2013-06-14 13:17 ` Roman Gushchin
  0 siblings, 0 replies; 25+ messages in thread
From: Roman Gushchin @ 2013-06-14 13:17 UTC (permalink / raw)
  To: cl, penberg, mpm, akpm, mgorman, rientjes, glommer, hannes,
	minchan, jiang.liu
  Cc: linux-mm, linux-kernel

Slub tries to use contiguous pages to fasten allocations and to minimize
management overhead. If necessary, it can easily fall back to the minimum
order allocations.

Slub tries to allocate contiguous pages even if memory is fragmented and
there are no free contiguous pages. In this case it calls direct compaction
to allocate contiguous page. Compaction requires the taking of some heavily
contended locks (e.g. zone locks). So, running compaction (direct and using
kswapd) simultaneously on several processors can cause serious performance
issues.

It's possible to avoid such problems (or at least to make them less probable)
by avoiding direct compaction. If it's not possible to allocate a contiguous
page without compaction, slub will fall back to order 0 page(s). In this case
kswapd will be woken to perform asynchronous compaction. So, slub can return
to default order allocations as soon as memory will be de-fragmented.

Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
---
  include/linux/gfp.h | 4 +++-
  mm/page_alloc.c     | 3 +++
  mm/slub.c           | 3 ++-
  3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 0f615eb..073a90a 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -35,6 +35,7 @@ struct vm_area_struct;
  #define ___GFP_NO_KSWAPD	0x400000u
  #define ___GFP_OTHER_NODE	0x800000u
  #define ___GFP_WRITE		0x1000000u
+#define ___GFP_NOCOMPACT	0x2000000u
  /* If the above are modified, __GFP_BITS_SHIFT may need updating */

  /*
@@ -92,6 +93,7 @@ struct vm_area_struct;
  #define __GFP_OTHER_NODE ((__force gfp_t)___GFP_OTHER_NODE) /* On behalf of other node */
  #define __GFP_KMEMCG	((__force gfp_t)___GFP_KMEMCG) /* Allocation comes from a memcg-accounted resource */
  #define __GFP_WRITE	((__force gfp_t)___GFP_WRITE)	/* Allocator intends to dirty page */
+#define __GFP_NOCOMPACT ((__force gfp_t)___GFP_NOCOMPACT) /* Avoid direct compaction */

  /*
   * This may seem redundant, but it's a way of annotating false positives vs.
@@ -99,7 +101,7 @@ struct vm_area_struct;
   */
  #define __GFP_NOTRACK_FALSE_POSITIVE (__GFP_NOTRACK)

-#define __GFP_BITS_SHIFT 25	/* Room for N __GFP_FOO bits */
+#define __GFP_BITS_SHIFT 26	/* Room for N __GFP_FOO bits */
  #define __GFP_BITS_MASK ((__force gfp_t)((1 << __GFP_BITS_SHIFT) - 1))

  /* This equals 0, but use constants in case they ever change */
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c3edb62..292562f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2482,6 +2482,9 @@ rebalance:
  	if (test_thread_flag(TIF_MEMDIE) && !(gfp_mask & __GFP_NOFAIL))
  		goto nopage;

+	if (order && (gfp_mask & __GFP_NOCOMPACT))
+		goto nopage;
+
  	/*
  	 * Try direct compaction. The first pass is asynchronous. Subsequent
  	 * attempts after direct reclaim are synchronous
diff --git a/mm/slub.c b/mm/slub.c
index 57707f0..a38733b 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1287,7 +1287,8 @@ static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int node)
  	 * Let the initial higher-order allocation fail under memory pressure
  	 * so we fall-back to the minimum order allocation.
  	 */
-	alloc_gfp = (flags | __GFP_NOWARN | __GFP_NORETRY) & ~__GFP_NOFAIL;
+	alloc_gfp = (flags | __GFP_NOWARN | __GFP_NORETRY | __GFP_NOCOMPACT) &
+		~__GFP_NOFAIL;

  	page = alloc_slab_page(alloc_gfp, node, oo);
  	if (unlikely(!page)) {
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 25+ messages in thread

* [PATCH] slub: Avoid direct compaction if possible
@ 2013-06-14 13:17 ` Roman Gushchin
  0 siblings, 0 replies; 25+ messages in thread
From: Roman Gushchin @ 2013-06-14 13:17 UTC (permalink / raw)
  To: cl, penberg, mpm, akpm, mgorman, rientjes, glommer, hannes,
	minchan, jiang.liu
  Cc: linux-mm, linux-kernel

Slub tries to use contiguous pages to fasten allocations and to minimize
management overhead. If necessary, it can easily fall back to the minimum
order allocations.

Slub tries to allocate contiguous pages even if memory is fragmented and
there are no free contiguous pages. In this case it calls direct compaction
to allocate contiguous page. Compaction requires the taking of some heavily
contended locks (e.g. zone locks). So, running compaction (direct and using
kswapd) simultaneously on several processors can cause serious performance
issues.

It's possible to avoid such problems (or at least to make them less probable)
by avoiding direct compaction. If it's not possible to allocate a contiguous
page without compaction, slub will fall back to order 0 page(s). In this case
kswapd will be woken to perform asynchronous compaction. So, slub can return
to default order allocations as soon as memory will be de-fragmented.

Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
---
  include/linux/gfp.h | 4 +++-
  mm/page_alloc.c     | 3 +++
  mm/slub.c           | 3 ++-
  3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 0f615eb..073a90a 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -35,6 +35,7 @@ struct vm_area_struct;
  #define ___GFP_NO_KSWAPD	0x400000u
  #define ___GFP_OTHER_NODE	0x800000u
  #define ___GFP_WRITE		0x1000000u
+#define ___GFP_NOCOMPACT	0x2000000u
  /* If the above are modified, __GFP_BITS_SHIFT may need updating */

  /*
@@ -92,6 +93,7 @@ struct vm_area_struct;
  #define __GFP_OTHER_NODE ((__force gfp_t)___GFP_OTHER_NODE) /* On behalf of other node */
  #define __GFP_KMEMCG	((__force gfp_t)___GFP_KMEMCG) /* Allocation comes from a memcg-accounted resource */
  #define __GFP_WRITE	((__force gfp_t)___GFP_WRITE)	/* Allocator intends to dirty page */
+#define __GFP_NOCOMPACT ((__force gfp_t)___GFP_NOCOMPACT) /* Avoid direct compaction */

  /*
   * This may seem redundant, but it's a way of annotating false positives vs.
@@ -99,7 +101,7 @@ struct vm_area_struct;
   */
  #define __GFP_NOTRACK_FALSE_POSITIVE (__GFP_NOTRACK)

-#define __GFP_BITS_SHIFT 25	/* Room for N __GFP_FOO bits */
+#define __GFP_BITS_SHIFT 26	/* Room for N __GFP_FOO bits */
  #define __GFP_BITS_MASK ((__force gfp_t)((1 << __GFP_BITS_SHIFT) - 1))

  /* This equals 0, but use constants in case they ever change */
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c3edb62..292562f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2482,6 +2482,9 @@ rebalance:
  	if (test_thread_flag(TIF_MEMDIE) && !(gfp_mask & __GFP_NOFAIL))
  		goto nopage;

+	if (order && (gfp_mask & __GFP_NOCOMPACT))
+		goto nopage;
+
  	/*
  	 * Try direct compaction. The first pass is asynchronous. Subsequent
  	 * attempts after direct reclaim are synchronous
diff --git a/mm/slub.c b/mm/slub.c
index 57707f0..a38733b 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1287,7 +1287,8 @@ static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int node)
  	 * Let the initial higher-order allocation fail under memory pressure
  	 * so we fall-back to the minimum order allocation.
  	 */
-	alloc_gfp = (flags | __GFP_NOWARN | __GFP_NORETRY) & ~__GFP_NOFAIL;
+	alloc_gfp = (flags | __GFP_NOWARN | __GFP_NORETRY | __GFP_NOCOMPACT) &
+		~__GFP_NOFAIL;

  	page = alloc_slab_page(alloc_gfp, node, oo);
  	if (unlikely(!page)) {
-- 
1.8.1.2

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

^ permalink raw reply related	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
  2013-06-14 13:17 ` Roman Gushchin
@ 2013-06-14 14:32   ` Christoph Lameter
  -1 siblings, 0 replies; 25+ messages in thread
From: Christoph Lameter @ 2013-06-14 14:32 UTC (permalink / raw)
  To: Roman Gushchin
  Cc: penberg, mpm, akpm, mgorman, rientjes, glommer, hannes, minchan,
	jiang.liu, linux-mm, linux-kernel

On Fri, 14 Jun 2013, Roman Gushchin wrote:

> Slub tries to allocate contiguous pages even if memory is fragmented and
> there are no free contiguous pages. In this case it calls direct compaction
> to allocate contiguous page. Compaction requires the taking of some heavily
> contended locks (e.g. zone locks). So, running compaction (direct and using
> kswapd) simultaneously on several processors can cause serious performance
> issues.

The main thing that this patch does is to add a nocompact flag to the page
allocator. That needs to be a separate patch. Also fix the description.
Slub does not invoke compaction. The page allocator initiates compaction
under certain conditions.

> It's possible to avoid such problems (or at least to make them less probable)
> by avoiding direct compaction. If it's not possible to allocate a contiguous
> page without compaction, slub will fall back to order 0 page(s). In this case
> kswapd will be woken to perform asynchronous compaction. So, slub can return
> to default order allocations as soon as memory will be de-fragmented.

Sounds like a good idea. Do you have some numbers to show the effect of
this patch?

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
@ 2013-06-14 14:32   ` Christoph Lameter
  0 siblings, 0 replies; 25+ messages in thread
From: Christoph Lameter @ 2013-06-14 14:32 UTC (permalink / raw)
  To: Roman Gushchin
  Cc: penberg, mpm, akpm, mgorman, rientjes, glommer, hannes, minchan,
	jiang.liu, linux-mm, linux-kernel

On Fri, 14 Jun 2013, Roman Gushchin wrote:

> Slub tries to allocate contiguous pages even if memory is fragmented and
> there are no free contiguous pages. In this case it calls direct compaction
> to allocate contiguous page. Compaction requires the taking of some heavily
> contended locks (e.g. zone locks). So, running compaction (direct and using
> kswapd) simultaneously on several processors can cause serious performance
> issues.

The main thing that this patch does is to add a nocompact flag to the page
allocator. That needs to be a separate patch. Also fix the description.
Slub does not invoke compaction. The page allocator initiates compaction
under certain conditions.

> It's possible to avoid such problems (or at least to make them less probable)
> by avoiding direct compaction. If it's not possible to allocate a contiguous
> page without compaction, slub will fall back to order 0 page(s). In this case
> kswapd will be woken to perform asynchronous compaction. So, slub can return
> to default order allocations as soon as memory will be de-fragmented.

Sounds like a good idea. Do you have some numbers to show the effect of
this patch?

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
  2013-06-14 14:32   ` Christoph Lameter
@ 2013-06-14 15:17     ` Roman Gushchin
  -1 siblings, 0 replies; 25+ messages in thread
From: Roman Gushchin @ 2013-06-14 15:17 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: penberg, mpm, akpm, mgorman, rientjes, glommer, hannes, minchan,
	jiang.liu, linux-mm, linux-kernel

On 14.06.2013 18:32, Christoph Lameter wrote:
> On Fri, 14 Jun 2013, Roman Gushchin wrote:
>
>> Slub tries to allocate contiguous pages even if memory is fragmented and
>> there are no free contiguous pages. In this case it calls direct compaction
>> to allocate contiguous page. Compaction requires the taking of some heavily
>> contended locks (e.g. zone locks). So, running compaction (direct and using
>> kswapd) simultaneously on several processors can cause serious performance
>> issues.
>
> The main thing that this patch does is to add a nocompact flag to the page
> allocator. That needs to be a separate patch. Also fix the description.
> Slub does not invoke compaction. The page allocator initiates compaction
> under certain conditions.

Ok, I'll do.

>
>> It's possible to avoid such problems (or at least to make them less probable)
>> by avoiding direct compaction. If it's not possible to allocate a contiguous
>> page without compaction, slub will fall back to order 0 page(s). In this case
>> kswapd will be woken to perform asynchronous compaction. So, slub can return
>> to default order allocations as soon as memory will be de-fragmented.
>
> Sounds like a good idea. Do you have some numbers to show the effect of
> this patch?

No.
It seems that any numbers here depend on memory fragmentation,
so it's not easy to make a reproducible measurement. If you have
any ideas here, you are welcome.

But there is an actual problem, that this patch solves.
Sometimes I saw the following issue on some machines:
all CPUs are performing compaction, system time is about 80%,
system is completely unreliable. It occurs only on machines
with specific workload (distributed data storage system, so,
intensive disk i/o is performed). A system can fall into
this state fast and unexpectedly or by progressive degradation.

This patch solves this problem.

Thank you for your comments and suggestions!

Regards,
Roman


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
@ 2013-06-14 15:17     ` Roman Gushchin
  0 siblings, 0 replies; 25+ messages in thread
From: Roman Gushchin @ 2013-06-14 15:17 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: penberg, mpm, akpm, mgorman, rientjes, glommer, hannes, minchan,
	jiang.liu, linux-mm, linux-kernel

On 14.06.2013 18:32, Christoph Lameter wrote:
> On Fri, 14 Jun 2013, Roman Gushchin wrote:
>
>> Slub tries to allocate contiguous pages even if memory is fragmented and
>> there are no free contiguous pages. In this case it calls direct compaction
>> to allocate contiguous page. Compaction requires the taking of some heavily
>> contended locks (e.g. zone locks). So, running compaction (direct and using
>> kswapd) simultaneously on several processors can cause serious performance
>> issues.
>
> The main thing that this patch does is to add a nocompact flag to the page
> allocator. That needs to be a separate patch. Also fix the description.
> Slub does not invoke compaction. The page allocator initiates compaction
> under certain conditions.

Ok, I'll do.

>
>> It's possible to avoid such problems (or at least to make them less probable)
>> by avoiding direct compaction. If it's not possible to allocate a contiguous
>> page without compaction, slub will fall back to order 0 page(s). In this case
>> kswapd will be woken to perform asynchronous compaction. So, slub can return
>> to default order allocations as soon as memory will be de-fragmented.
>
> Sounds like a good idea. Do you have some numbers to show the effect of
> this patch?

No.
It seems that any numbers here depend on memory fragmentation,
so it's not easy to make a reproducible measurement. If you have
any ideas here, you are welcome.

But there is an actual problem, that this patch solves.
Sometimes I saw the following issue on some machines:
all CPUs are performing compaction, system time is about 80%,
system is completely unreliable. It occurs only on machines
with specific workload (distributed data storage system, so,
intensive disk i/o is performed). A system can fall into
this state fast and unexpectedly or by progressive degradation.

This patch solves this problem.

Thank you for your comments and suggestions!

Regards,
Roman

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
  2013-06-14 15:17     ` Roman Gushchin
@ 2013-06-14 16:08       ` Christoph Lameter
  -1 siblings, 0 replies; 25+ messages in thread
From: Christoph Lameter @ 2013-06-14 16:08 UTC (permalink / raw)
  To: Roman Gushchin
  Cc: Pekka Enberg, mpm, akpm, mgorman, David Rientjes, glommer,
	hannes, minchan, jiang.liu, linux-mm, linux-kernel

On Fri, 14 Jun 2013, Roman Gushchin wrote:

> But there is an actual problem, that this patch solves.
> Sometimes I saw the following issue on some machines:
> all CPUs are performing compaction, system time is about 80%,
> system is completely unreliable. It occurs only on machines
> with specific workload (distributed data storage system, so,
> intensive disk i/o is performed). A system can fall into
> this state fast and unexpectedly or by progressive degradation.

Well that is not a slab allocator specific issue but related to compaction
concurrency. Likely cache line contention is causing a severe slowday. But
that issue could be triggered by any subsystem that does lots of memory
allocations. I would suggest that we try to address the problem in the
compaction logic rather than modifying allocators.

Mel?

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
@ 2013-06-14 16:08       ` Christoph Lameter
  0 siblings, 0 replies; 25+ messages in thread
From: Christoph Lameter @ 2013-06-14 16:08 UTC (permalink / raw)
  To: Roman Gushchin
  Cc: Pekka Enberg, mpm, akpm, mgorman, David Rientjes, glommer,
	hannes, minchan, jiang.liu, linux-mm, linux-kernel

On Fri, 14 Jun 2013, Roman Gushchin wrote:

> But there is an actual problem, that this patch solves.
> Sometimes I saw the following issue on some machines:
> all CPUs are performing compaction, system time is about 80%,
> system is completely unreliable. It occurs only on machines
> with specific workload (distributed data storage system, so,
> intensive disk i/o is performed). A system can fall into
> this state fast and unexpectedly or by progressive degradation.

Well that is not a slab allocator specific issue but related to compaction
concurrency. Likely cache line contention is causing a severe slowday. But
that issue could be triggered by any subsystem that does lots of memory
allocations. I would suggest that we try to address the problem in the
compaction logic rather than modifying allocators.

Mel?

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
  2013-06-14 16:08       ` Christoph Lameter
@ 2013-06-14 16:52         ` Roman Gushchin
  -1 siblings, 0 replies; 25+ messages in thread
From: Roman Gushchin @ 2013-06-14 16:52 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: Pekka Enberg, mpm, akpm, mgorman, David Rientjes, glommer,
	hannes, minchan, jiang.liu, linux-mm, linux-kernel

On 14.06.2013 20:08, Christoph Lameter wrote:
> On Fri, 14 Jun 2013, Roman Gushchin wrote:
>
>> But there is an actual problem, that this patch solves.
>> Sometimes I saw the following issue on some machines:
>> all CPUs are performing compaction, system time is about 80%,
>> system is completely unreliable. It occurs only on machines
>> with specific workload (distributed data storage system, so,
>> intensive disk i/o is performed). A system can fall into
>> this state fast and unexpectedly or by progressive degradation.
>
> Well that is not a slab allocator specific issue but related to compaction
> concurrency. Likely cache line contention is causing a severe slowday. But
> that issue could be triggered by any subsystem that does lots of memory
> allocations. I would suggest that we try to address the problem in the
> compaction logic rather than modifying allocators.

I agree, that it's good to address the original issue. But I'm not sure,
that it's a compaction issue. If someone wants to participate here,
I can provide more information. The main problem here is that it's
__very__ hard to reproduce the issue.

But, I think, all that shouldn't stop us from modifying the allocator.
Falling back to minimal order is in any case better than running
direct compaction. Just because it's faster. Am I wrong?

Regards,
Roman

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
@ 2013-06-14 16:52         ` Roman Gushchin
  0 siblings, 0 replies; 25+ messages in thread
From: Roman Gushchin @ 2013-06-14 16:52 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: Pekka Enberg, mpm, akpm, mgorman, David Rientjes, glommer,
	hannes, minchan, jiang.liu, linux-mm, linux-kernel

On 14.06.2013 20:08, Christoph Lameter wrote:
> On Fri, 14 Jun 2013, Roman Gushchin wrote:
>
>> But there is an actual problem, that this patch solves.
>> Sometimes I saw the following issue on some machines:
>> all CPUs are performing compaction, system time is about 80%,
>> system is completely unreliable. It occurs only on machines
>> with specific workload (distributed data storage system, so,
>> intensive disk i/o is performed). A system can fall into
>> this state fast and unexpectedly or by progressive degradation.
>
> Well that is not a slab allocator specific issue but related to compaction
> concurrency. Likely cache line contention is causing a severe slowday. But
> that issue could be triggered by any subsystem that does lots of memory
> allocations. I would suggest that we try to address the problem in the
> compaction logic rather than modifying allocators.

I agree, that it's good to address the original issue. But I'm not sure,
that it's a compaction issue. If someone wants to participate here,
I can provide more information. The main problem here is that it's
__very__ hard to reproduce the issue.

But, I think, all that shouldn't stop us from modifying the allocator.
Falling back to minimal order is in any case better than running
direct compaction. Just because it's faster. Am I wrong?

Regards,
Roman

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
  2013-06-14 14:32   ` Christoph Lameter
@ 2013-06-14 20:26     ` David Rientjes
  -1 siblings, 0 replies; 25+ messages in thread
From: David Rientjes @ 2013-06-14 20:26 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: Roman Gushchin, penberg, mpm, akpm, mgorman, glommer, hannes,
	minchan, jiang.liu, linux-mm, linux-kernel

On Fri, 14 Jun 2013, Christoph Lameter wrote:

> > It's possible to avoid such problems (or at least to make them less probable)
> > by avoiding direct compaction. If it's not possible to allocate a contiguous
> > page without compaction, slub will fall back to order 0 page(s). In this case
> > kswapd will be woken to perform asynchronous compaction. So, slub can return
> > to default order allocations as soon as memory will be de-fragmented.
> 
> Sounds like a good idea. Do you have some numbers to show the effect of
> this patch?
> 

I'm surprised you like this patch, it basically makes slub allocations to 
be atomic and doesn't try memory compaction nor reclaim.  Asynchronous 
compaction certainly isn't aggressive enough to mimick the effects of the 
old lumpy reclaim that would have resulted in less fragmented memory.  If 
slub is the only thing that is doing high-order allocations, it will start 
falling back to the smallest page order much much more often.

I agree that this doesn't seem like a slub issue at all but rather a page 
allocator issue; if we have many simultaneous thp faults at the same time 
and /sys/kernel/mm/transparent_hugepage/defrag is "always" then you'll get 
the same problem if deferred compaction isn't helping.

So I don't think we should be patching slub in any special way here.

Roman, are you using the latest kernel?  If so, what does
grep compact_ /proc/vmstat show after one or more of these events?

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
@ 2013-06-14 20:26     ` David Rientjes
  0 siblings, 0 replies; 25+ messages in thread
From: David Rientjes @ 2013-06-14 20:26 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: Roman Gushchin, penberg, mpm, akpm, mgorman, glommer, hannes,
	minchan, jiang.liu, linux-mm, linux-kernel

On Fri, 14 Jun 2013, Christoph Lameter wrote:

> > It's possible to avoid such problems (or at least to make them less probable)
> > by avoiding direct compaction. If it's not possible to allocate a contiguous
> > page without compaction, slub will fall back to order 0 page(s). In this case
> > kswapd will be woken to perform asynchronous compaction. So, slub can return
> > to default order allocations as soon as memory will be de-fragmented.
> 
> Sounds like a good idea. Do you have some numbers to show the effect of
> this patch?
> 

I'm surprised you like this patch, it basically makes slub allocations to 
be atomic and doesn't try memory compaction nor reclaim.  Asynchronous 
compaction certainly isn't aggressive enough to mimick the effects of the 
old lumpy reclaim that would have resulted in less fragmented memory.  If 
slub is the only thing that is doing high-order allocations, it will start 
falling back to the smallest page order much much more often.

I agree that this doesn't seem like a slub issue at all but rather a page 
allocator issue; if we have many simultaneous thp faults at the same time 
and /sys/kernel/mm/transparent_hugepage/defrag is "always" then you'll get 
the same problem if deferred compaction isn't helping.

So I don't think we should be patching slub in any special way here.

Roman, are you using the latest kernel?  If so, what does
grep compact_ /proc/vmstat show after one or more of these events?

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
  2013-06-14 20:26     ` David Rientjes
@ 2013-06-17 12:34       ` Roman Gushchin
  -1 siblings, 0 replies; 25+ messages in thread
From: Roman Gushchin @ 2013-06-17 12:34 UTC (permalink / raw)
  To: David Rientjes
  Cc: Christoph Lameter, penberg, mpm, akpm, mgorman, glommer, hannes,
	minchan, jiang.liu, linux-mm, linux-kernel

On 15.06.2013 00:26, David Rientjes wrote:
> On Fri, 14 Jun 2013, Christoph Lameter wrote:
>
>>> It's possible to avoid such problems (or at least to make them less probable)
>>> by avoiding direct compaction. If it's not possible to allocate a contiguous
>>> page without compaction, slub will fall back to order 0 page(s). In this case
>>> kswapd will be woken to perform asynchronous compaction. So, slub can return
>>> to default order allocations as soon as memory will be de-fragmented.
>>
>> Sounds like a good idea. Do you have some numbers to show the effect of
>> this patch?
>>
>
> I'm surprised you like this patch, it basically makes slub allocations to
> be atomic and doesn't try memory compaction nor reclaim.  Asynchronous
> compaction certainly isn't aggressive enough to mimick the effects of the
> old lumpy reclaim that would have resulted in less fragmented memory.  If
> slub is the only thing that is doing high-order allocations, it will start
> falling back to the smallest page order much much more often.
>
> I agree that this doesn't seem like a slub issue at all but rather a page
> allocator issue; if we have many simultaneous thp faults at the same time
> and /sys/kernel/mm/transparent_hugepage/defrag is "always" then you'll get
> the same problem if deferred compaction isn't helping.
>
> So I don't think we should be patching slub in any special way here.
>
> Roman, are you using the latest kernel?  If so, what does
> grep compact_ /proc/vmstat show after one or more of these events?
>

We're using 3.4. And the problem reveals when we moved from 3.2 to 3.4.
It can be also reproduced on 3.5.

I'll send the exact numbers as soon I'll reproduce it again.
It can take up to 1 week.

Thanks!

Regards,
Roman

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
@ 2013-06-17 12:34       ` Roman Gushchin
  0 siblings, 0 replies; 25+ messages in thread
From: Roman Gushchin @ 2013-06-17 12:34 UTC (permalink / raw)
  To: David Rientjes
  Cc: Christoph Lameter, penberg, mpm, akpm, mgorman, glommer, hannes,
	minchan, jiang.liu, linux-mm, linux-kernel

On 15.06.2013 00:26, David Rientjes wrote:
> On Fri, 14 Jun 2013, Christoph Lameter wrote:
>
>>> It's possible to avoid such problems (or at least to make them less probable)
>>> by avoiding direct compaction. If it's not possible to allocate a contiguous
>>> page without compaction, slub will fall back to order 0 page(s). In this case
>>> kswapd will be woken to perform asynchronous compaction. So, slub can return
>>> to default order allocations as soon as memory will be de-fragmented.
>>
>> Sounds like a good idea. Do you have some numbers to show the effect of
>> this patch?
>>
>
> I'm surprised you like this patch, it basically makes slub allocations to
> be atomic and doesn't try memory compaction nor reclaim.  Asynchronous
> compaction certainly isn't aggressive enough to mimick the effects of the
> old lumpy reclaim that would have resulted in less fragmented memory.  If
> slub is the only thing that is doing high-order allocations, it will start
> falling back to the smallest page order much much more often.
>
> I agree that this doesn't seem like a slub issue at all but rather a page
> allocator issue; if we have many simultaneous thp faults at the same time
> and /sys/kernel/mm/transparent_hugepage/defrag is "always" then you'll get
> the same problem if deferred compaction isn't helping.
>
> So I don't think we should be patching slub in any special way here.
>
> Roman, are you using the latest kernel?  If so, what does
> grep compact_ /proc/vmstat show after one or more of these events?
>

We're using 3.4. And the problem reveals when we moved from 3.2 to 3.4.
It can be also reproduced on 3.5.

I'll send the exact numbers as soon I'll reproduce it again.
It can take up to 1 week.

Thanks!

Regards,
Roman

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
  2013-06-17 12:34       ` Roman Gushchin
@ 2013-06-17 14:27         ` Michal Hocko
  -1 siblings, 0 replies; 25+ messages in thread
From: Michal Hocko @ 2013-06-17 14:27 UTC (permalink / raw)
  To: Roman Gushchin
  Cc: David Rientjes, Christoph Lameter, penberg, mpm, akpm, mgorman,
	glommer, hannes, minchan, jiang.liu, linux-mm, linux-kernel

On Mon 17-06-13 16:34:23, Roman Gushchin wrote:
> On 15.06.2013 00:26, David Rientjes wrote:
> >On Fri, 14 Jun 2013, Christoph Lameter wrote:
> >
> >>>It's possible to avoid such problems (or at least to make them less probable)
> >>>by avoiding direct compaction. If it's not possible to allocate a contiguous
> >>>page without compaction, slub will fall back to order 0 page(s). In this case
> >>>kswapd will be woken to perform asynchronous compaction. So, slub can return
> >>>to default order allocations as soon as memory will be de-fragmented.
> >>
> >>Sounds like a good idea. Do you have some numbers to show the effect of
> >>this patch?
> >>
> >
> >I'm surprised you like this patch, it basically makes slub allocations to
> >be atomic and doesn't try memory compaction nor reclaim.  Asynchronous
> >compaction certainly isn't aggressive enough to mimick the effects of the
> >old lumpy reclaim that would have resulted in less fragmented memory.  If
> >slub is the only thing that is doing high-order allocations, it will start
> >falling back to the smallest page order much much more often.
> >
> >I agree that this doesn't seem like a slub issue at all but rather a page
> >allocator issue; if we have many simultaneous thp faults at the same time
> >and /sys/kernel/mm/transparent_hugepage/defrag is "always" then you'll get
> >the same problem if deferred compaction isn't helping.
> >
> >So I don't think we should be patching slub in any special way here.
> >
> >Roman, are you using the latest kernel?  If so, what does
> >grep compact_ /proc/vmstat show after one or more of these events?
> >
> 
> We're using 3.4. And the problem reveals when we moved from 3.2 to 3.4.
> It can be also reproduced on 3.5.

FWIW, there were some compaction locking related patches merged
around 3.7. See 2a1402aa044b55c2d30ab0ed9405693ef06fb07c and follow ups.

> I'll send the exact numbers as soon I'll reproduce it again.
> It can take up to 1 week.
> 
> Thanks!
> 
> Regards,
> Roman
> 
> --
> 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>

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
@ 2013-06-17 14:27         ` Michal Hocko
  0 siblings, 0 replies; 25+ messages in thread
From: Michal Hocko @ 2013-06-17 14:27 UTC (permalink / raw)
  To: Roman Gushchin
  Cc: David Rientjes, Christoph Lameter, penberg, mpm, akpm, mgorman,
	glommer, hannes, minchan, jiang.liu, linux-mm, linux-kernel

On Mon 17-06-13 16:34:23, Roman Gushchin wrote:
> On 15.06.2013 00:26, David Rientjes wrote:
> >On Fri, 14 Jun 2013, Christoph Lameter wrote:
> >
> >>>It's possible to avoid such problems (or at least to make them less probable)
> >>>by avoiding direct compaction. If it's not possible to allocate a contiguous
> >>>page without compaction, slub will fall back to order 0 page(s). In this case
> >>>kswapd will be woken to perform asynchronous compaction. So, slub can return
> >>>to default order allocations as soon as memory will be de-fragmented.
> >>
> >>Sounds like a good idea. Do you have some numbers to show the effect of
> >>this patch?
> >>
> >
> >I'm surprised you like this patch, it basically makes slub allocations to
> >be atomic and doesn't try memory compaction nor reclaim.  Asynchronous
> >compaction certainly isn't aggressive enough to mimick the effects of the
> >old lumpy reclaim that would have resulted in less fragmented memory.  If
> >slub is the only thing that is doing high-order allocations, it will start
> >falling back to the smallest page order much much more often.
> >
> >I agree that this doesn't seem like a slub issue at all but rather a page
> >allocator issue; if we have many simultaneous thp faults at the same time
> >and /sys/kernel/mm/transparent_hugepage/defrag is "always" then you'll get
> >the same problem if deferred compaction isn't helping.
> >
> >So I don't think we should be patching slub in any special way here.
> >
> >Roman, are you using the latest kernel?  If so, what does
> >grep compact_ /proc/vmstat show after one or more of these events?
> >
> 
> We're using 3.4. And the problem reveals when we moved from 3.2 to 3.4.
> It can be also reproduced on 3.5.

FWIW, there were some compaction locking related patches merged
around 3.7. See 2a1402aa044b55c2d30ab0ed9405693ef06fb07c and follow ups.

> I'll send the exact numbers as soon I'll reproduce it again.
> It can take up to 1 week.
> 
> Thanks!
> 
> Regards,
> Roman
> 
> --
> 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>

-- 
Michal Hocko
SUSE Labs

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
  2013-06-17 14:27         ` Michal Hocko
@ 2013-06-17 14:54           ` Roman Gushchin
  -1 siblings, 0 replies; 25+ messages in thread
From: Roman Gushchin @ 2013-06-17 14:54 UTC (permalink / raw)
  To: Michal Hocko
  Cc: David Rientjes, Christoph Lameter, penberg, mpm, akpm, mgorman,
	glommer, hannes, minchan, jiang.liu, linux-mm, linux-kernel

On 17.06.2013 18:27, Michal Hocko wrote:
> On Mon 17-06-13 16:34:23, Roman Gushchin wrote:
>> On 15.06.2013 00:26, David Rientjes wrote:
>>> On Fri, 14 Jun 2013, Christoph Lameter wrote:
>>>
>>>>> It's possible to avoid such problems (or at least to make them less probable)
>>>>> by avoiding direct compaction. If it's not possible to allocate a contiguous
>>>>> page without compaction, slub will fall back to order 0 page(s). In this case
>>>>> kswapd will be woken to perform asynchronous compaction. So, slub can return
>>>>> to default order allocations as soon as memory will be de-fragmented.
>>>>
>>>> Sounds like a good idea. Do you have some numbers to show the effect of
>>>> this patch?
>>>>
>>>
>>> I'm surprised you like this patch, it basically makes slub allocations to
>>> be atomic and doesn't try memory compaction nor reclaim.  Asynchronous
>>> compaction certainly isn't aggressive enough to mimick the effects of the
>>> old lumpy reclaim that would have resulted in less fragmented memory.  If
>>> slub is the only thing that is doing high-order allocations, it will start
>>> falling back to the smallest page order much much more often.
>>>
>>> I agree that this doesn't seem like a slub issue at all but rather a page
>>> allocator issue; if we have many simultaneous thp faults at the same time
>>> and /sys/kernel/mm/transparent_hugepage/defrag is "always" then you'll get
>>> the same problem if deferred compaction isn't helping.
>>>
>>> So I don't think we should be patching slub in any special way here.
>>>
>>> Roman, are you using the latest kernel?  If so, what does
>>> grep compact_ /proc/vmstat show after one or more of these events?
>>>
>>
>> We're using 3.4. And the problem reveals when we moved from 3.2 to 3.4.
>> It can be also reproduced on 3.5.
>
> FWIW, there were some compaction locking related patches merged
> around 3.7. See 2a1402aa044b55c2d30ab0ed9405693ef06fb07c and follow ups.

Thanks, Michal.
I've already tried to backport some of those patches, but it didn't help
(may be it wasn't enough).
I'll try to reproduce the issue on raw 3.9.

Regards,
Roman

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
@ 2013-06-17 14:54           ` Roman Gushchin
  0 siblings, 0 replies; 25+ messages in thread
From: Roman Gushchin @ 2013-06-17 14:54 UTC (permalink / raw)
  To: Michal Hocko
  Cc: David Rientjes, Christoph Lameter, penberg, mpm, akpm, mgorman,
	glommer, hannes, minchan, jiang.liu, linux-mm, linux-kernel

On 17.06.2013 18:27, Michal Hocko wrote:
> On Mon 17-06-13 16:34:23, Roman Gushchin wrote:
>> On 15.06.2013 00:26, David Rientjes wrote:
>>> On Fri, 14 Jun 2013, Christoph Lameter wrote:
>>>
>>>>> It's possible to avoid such problems (or at least to make them less probable)
>>>>> by avoiding direct compaction. If it's not possible to allocate a contiguous
>>>>> page without compaction, slub will fall back to order 0 page(s). In this case
>>>>> kswapd will be woken to perform asynchronous compaction. So, slub can return
>>>>> to default order allocations as soon as memory will be de-fragmented.
>>>>
>>>> Sounds like a good idea. Do you have some numbers to show the effect of
>>>> this patch?
>>>>
>>>
>>> I'm surprised you like this patch, it basically makes slub allocations to
>>> be atomic and doesn't try memory compaction nor reclaim.  Asynchronous
>>> compaction certainly isn't aggressive enough to mimick the effects of the
>>> old lumpy reclaim that would have resulted in less fragmented memory.  If
>>> slub is the only thing that is doing high-order allocations, it will start
>>> falling back to the smallest page order much much more often.
>>>
>>> I agree that this doesn't seem like a slub issue at all but rather a page
>>> allocator issue; if we have many simultaneous thp faults at the same time
>>> and /sys/kernel/mm/transparent_hugepage/defrag is "always" then you'll get
>>> the same problem if deferred compaction isn't helping.
>>>
>>> So I don't think we should be patching slub in any special way here.
>>>
>>> Roman, are you using the latest kernel?  If so, what does
>>> grep compact_ /proc/vmstat show after one or more of these events?
>>>
>>
>> We're using 3.4. And the problem reveals when we moved from 3.2 to 3.4.
>> It can be also reproduced on 3.5.
>
> FWIW, there were some compaction locking related patches merged
> around 3.7. See 2a1402aa044b55c2d30ab0ed9405693ef06fb07c and follow ups.

Thanks, Michal.
I've already tried to backport some of those patches, but it didn't help
(may be it wasn't enough).
I'll try to reproduce the issue on raw 3.9.

Regards,
Roman

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
  2013-06-17 14:54           ` Roman Gushchin
@ 2013-06-17 21:44             ` David Rientjes
  -1 siblings, 0 replies; 25+ messages in thread
From: David Rientjes @ 2013-06-17 21:44 UTC (permalink / raw)
  To: Roman Gushchin
  Cc: Michal Hocko, Christoph Lameter, penberg, mpm, akpm, mgorman,
	glommer, hannes, minchan, jiang.liu, linux-mm, linux-kernel

On Mon, 17 Jun 2013, Roman Gushchin wrote:

> > FWIW, there were some compaction locking related patches merged
> > around 3.7. See 2a1402aa044b55c2d30ab0ed9405693ef06fb07c and follow ups.
> 
> Thanks, Michal.
> I've already tried to backport some of those patches, but it didn't help
> (may be it wasn't enough).

They certainly aren't enough, the kernel you're running suffers from a 
couple different memory compaction issues that were fixed in 3.7.  I 
couldn't sympathize with your situation more, I faced the same issue 
because of thp and not slub (we use slab).

> I'll try to reproduce the issue on raw 3.9.
> 

Thanks.  If you need to go back to 3.4, try using these, they 
significantly helped our issues:

bb13ffeb9f6bfeb301443994dfbf29f91117dfb3
627260595ca6abcb16d68a3732bac6b547e112d6
c89511ab2f8fe2b47585e60da8af7fd213ec877e
62997027ca5b3d4618198ed8b1aba40b61b1137b
a9aacbccf3145355190d87f0df1731fb84fdd8c8

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
@ 2013-06-17 21:44             ` David Rientjes
  0 siblings, 0 replies; 25+ messages in thread
From: David Rientjes @ 2013-06-17 21:44 UTC (permalink / raw)
  To: Roman Gushchin
  Cc: Michal Hocko, Christoph Lameter, penberg, mpm, akpm, mgorman,
	glommer, hannes, minchan, jiang.liu, linux-mm, linux-kernel

On Mon, 17 Jun 2013, Roman Gushchin wrote:

> > FWIW, there were some compaction locking related patches merged
> > around 3.7. See 2a1402aa044b55c2d30ab0ed9405693ef06fb07c and follow ups.
> 
> Thanks, Michal.
> I've already tried to backport some of those patches, but it didn't help
> (may be it wasn't enough).

They certainly aren't enough, the kernel you're running suffers from a 
couple different memory compaction issues that were fixed in 3.7.  I 
couldn't sympathize with your situation more, I faced the same issue 
because of thp and not slub (we use slab).

> I'll try to reproduce the issue on raw 3.9.
> 

Thanks.  If you need to go back to 3.4, try using these, they 
significantly helped our issues:

bb13ffeb9f6bfeb301443994dfbf29f91117dfb3
627260595ca6abcb16d68a3732bac6b547e112d6
c89511ab2f8fe2b47585e60da8af7fd213ec877e
62997027ca5b3d4618198ed8b1aba40b61b1137b
a9aacbccf3145355190d87f0df1731fb84fdd8c8

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
  2013-06-17 21:44             ` David Rientjes
@ 2013-06-27  8:49               ` Roman Gushchin
  -1 siblings, 0 replies; 25+ messages in thread
From: Roman Gushchin @ 2013-06-27  8:49 UTC (permalink / raw)
  To: David Rientjes
  Cc: Michal Hocko, Christoph Lameter, penberg, mpm, akpm, mgorman,
	glommer, hannes, minchan, jiang.liu, linux-mm, linux-kernel

On 18.06.2013 01:44, David Rientjes wrote:
> On Mon, 17 Jun 2013, Roman Gushchin wrote:

> They certainly aren't enough, the kernel you're running suffers from a
> couple different memory compaction issues that were fixed in 3.7.  I
> couldn't sympathize with your situation more, I faced the same issue
> because of thp and not slub (we use slab).
>
>> I'll try to reproduce the issue on raw 3.9.
>>

I can't reproduce the issue on 3.9.
It seems that compaction fixes in 3.7 solve the problem.

>
> Thanks.  If you need to go back to 3.4, try using these, they
> significantly helped our issues:
>
> bb13ffeb9f6bfeb301443994dfbf29f91117dfb3
> 627260595ca6abcb16d68a3732bac6b547e112d6
> c89511ab2f8fe2b47585e60da8af7fd213ec877e
> 62997027ca5b3d4618198ed8b1aba40b61b1137b
> a9aacbccf3145355190d87f0df1731fb84fdd8c8

Thank you!

Regards,
Roman



^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
@ 2013-06-27  8:49               ` Roman Gushchin
  0 siblings, 0 replies; 25+ messages in thread
From: Roman Gushchin @ 2013-06-27  8:49 UTC (permalink / raw)
  To: David Rientjes
  Cc: Michal Hocko, Christoph Lameter, penberg, mpm, akpm, mgorman,
	glommer, hannes, minchan, jiang.liu, linux-mm, linux-kernel

On 18.06.2013 01:44, David Rientjes wrote:
> On Mon, 17 Jun 2013, Roman Gushchin wrote:

> They certainly aren't enough, the kernel you're running suffers from a
> couple different memory compaction issues that were fixed in 3.7.  I
> couldn't sympathize with your situation more, I faced the same issue
> because of thp and not slub (we use slab).
>
>> I'll try to reproduce the issue on raw 3.9.
>>

I can't reproduce the issue on 3.9.
It seems that compaction fixes in 3.7 solve the problem.

>
> Thanks.  If you need to go back to 3.4, try using these, they
> significantly helped our issues:
>
> bb13ffeb9f6bfeb301443994dfbf29f91117dfb3
> 627260595ca6abcb16d68a3732bac6b547e112d6
> c89511ab2f8fe2b47585e60da8af7fd213ec877e
> 62997027ca5b3d4618198ed8b1aba40b61b1137b
> a9aacbccf3145355190d87f0df1731fb84fdd8c8

Thank you!

Regards,
Roman


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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
  2013-06-27  8:49               ` Roman Gushchin
@ 2013-06-27 20:41                 ` David Rientjes
  -1 siblings, 0 replies; 25+ messages in thread
From: David Rientjes @ 2013-06-27 20:41 UTC (permalink / raw)
  To: Roman Gushchin
  Cc: Michal Hocko, Christoph Lameter, penberg, mpm, akpm, mgorman,
	glommer, hannes, minchan, jiang.liu, linux-mm, linux-kernel

On Thu, 27 Jun 2013, Roman Gushchin wrote:

> > They certainly aren't enough, the kernel you're running suffers from a
> > couple different memory compaction issues that were fixed in 3.7.  I
> > couldn't sympathize with your situation more, I faced the same issue
> > because of thp and not slub (we use slab).
> > 
> > > I'll try to reproduce the issue on raw 3.9.
> > > 
> 
> I can't reproduce the issue on 3.9.
> It seems that compaction fixes in 3.7 solve the problem.
> 

Yeah, we had significant problems with memory compaction in 3.3 and 3.4 
kernels, so if you need to run with such a kernel you'll want to backport 
the listed commits.  I'm not sure we could get such invasive changes into 
a stable release, unfortunately.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
@ 2013-06-27 20:41                 ` David Rientjes
  0 siblings, 0 replies; 25+ messages in thread
From: David Rientjes @ 2013-06-27 20:41 UTC (permalink / raw)
  To: Roman Gushchin
  Cc: Michal Hocko, Christoph Lameter, penberg, mpm, akpm, mgorman,
	glommer, hannes, minchan, jiang.liu, linux-mm, linux-kernel

On Thu, 27 Jun 2013, Roman Gushchin wrote:

> > They certainly aren't enough, the kernel you're running suffers from a
> > couple different memory compaction issues that were fixed in 3.7.  I
> > couldn't sympathize with your situation more, I faced the same issue
> > because of thp and not slub (we use slab).
> > 
> > > I'll try to reproduce the issue on raw 3.9.
> > > 
> 
> I can't reproduce the issue on 3.9.
> It seems that compaction fixes in 3.7 solve the problem.
> 

Yeah, we had significant problems with memory compaction in 3.3 and 3.4 
kernels, so if you need to run with such a kernel you'll want to backport 
the listed commits.  I'm not sure we could get such invasive changes into 
a stable release, unfortunately.

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] slub: Avoid direct compaction if possible
  2013-06-27 20:41                 ` David Rientjes
  (?)
@ 2013-07-18 20:29                 ` Vinson Lee
  -1 siblings, 0 replies; 25+ messages in thread
From: Vinson Lee @ 2013-07-18 20:29 UTC (permalink / raw)
  To: David Rientjes
  Cc: Roman Gushchin, Michal Hocko, Christoph Lameter, penberg, mpm,
	akpm, mgorman, glommer, hannes, minchan, jiang.liu, linux-mm, li

On Thu, Jun 27, 2013 at 1:41 PM, David Rientjes <rientjes@google.com> wrote:
> On Thu, 27 Jun 2013, Roman Gushchin wrote:
>
>> > They certainly aren't enough, the kernel you're running suffers from a
>> > couple different memory compaction issues that were fixed in 3.7.  I
>> > couldn't sympathize with your situation more, I faced the same issue
>> > because of thp and not slub (we use slab).
>> >
>> > > I'll try to reproduce the issue on raw 3.9.
>> > >
>>
>> I can't reproduce the issue on 3.9.
>> It seems that compaction fixes in 3.7 solve the problem.
>>
>
> Yeah, we had significant problems with memory compaction in 3.3 and 3.4
> kernels, so if you need to run with such a kernel you'll want to backport
> the listed commits.  I'm not sure we could get such invasive changes into
> a stable release, unfortunately.

Hi.

Can the diff with the backport of the listed patches be posted? The
patches don't easily apply to 3.4.

I think I'm seeing memory compaction issues as well with Linux kernel
3.4 and would welcome any help. I'm planning to try the backporting
approach to see if it improves things on my side.

Cheers,
Vinson

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2013-07-18 20:29 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-14 13:17 [PATCH] slub: Avoid direct compaction if possible Roman Gushchin
2013-06-14 13:17 ` Roman Gushchin
2013-06-14 14:32 ` Christoph Lameter
2013-06-14 14:32   ` Christoph Lameter
2013-06-14 15:17   ` Roman Gushchin
2013-06-14 15:17     ` Roman Gushchin
2013-06-14 16:08     ` Christoph Lameter
2013-06-14 16:08       ` Christoph Lameter
2013-06-14 16:52       ` Roman Gushchin
2013-06-14 16:52         ` Roman Gushchin
2013-06-14 20:26   ` David Rientjes
2013-06-14 20:26     ` David Rientjes
2013-06-17 12:34     ` Roman Gushchin
2013-06-17 12:34       ` Roman Gushchin
2013-06-17 14:27       ` Michal Hocko
2013-06-17 14:27         ` Michal Hocko
2013-06-17 14:54         ` Roman Gushchin
2013-06-17 14:54           ` Roman Gushchin
2013-06-17 21:44           ` David Rientjes
2013-06-17 21:44             ` David Rientjes
2013-06-27  8:49             ` Roman Gushchin
2013-06-27  8:49               ` Roman Gushchin
2013-06-27 20:41               ` David Rientjes
2013-06-27 20:41                 ` David Rientjes
2013-07-18 20:29                 ` Vinson Lee

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.