[PATCH 0/2] Avoid excessive reclaim due to THP

[PATCH 0/2] Avoid excessive reclaim due to THP

[Mel Gorman]

The thread "[PATCH v2 -mm] limit direct reclaim for higher order
allocations" went silent so this is an attempt to kick it awake again
to close it.

Rik noticed that there was too much memory free on his machine when
THP was running and there is at least one bug report out there that
implies that reclaim due to khugepaged is causing stalls.

In Rik's case, he posted a patch that fixed his
problem. The user on the RH bug reported that a patch from
https://lkml.org/lkml/2011/7/26/103 fixed his problem. However, in many
cases, these patches are complimentary except that Rik's is tidier.

Patch 1 of this series is a patch from Rik that limits the amount
of direct reclaim that occurs as a result of THP. Specifically,
if compaction can go ahead in a zone or is deferred for a zonelist,
then reclaim will stop as it is unlikely freeing more pages will help.

Patch 2 notes that even if patch 1 stops reclaiming, the caller
of shrink_zones will still shrink slabs and scan at the next
priority.  This is unnecessary and wasteful so the patch causes
do_try_to_free_pages() to abort reclaim if shrink_zones() returned
early.

Rik, can you retest with your case just to be sure? Josh, will you
ask the reporter of RH#735946 to retest with these patches to ensure
their problem really gets fixed upstream?

I tested it myself and it appears to behave as expected. Performance
of benchmarks like STREAM that benefit from THP are unchanged
as expected. When running with a basic workload that created a
large anonymous mapping and read it multiple times followed by
writing it multiple times, there are fewer pages direct reclaimed.
Critically, memory utilisation is higher with these patches applied
as predicted. In the vanilla kernel, I can see a few spikes where an
excessive amount of memory memory was reclaimed that is not present
with the patches applied.

Are there any objections to these being merged?

 mm/vmscan.c |   26 ++++++++++++++++++++++++--
 1 files changed, 24 insertions(+), 2 deletions(-)

-- 
1.7.3.4

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 1/2] mm: vmscan: Limit direct reclaim for higher order allocations

[Mel Gorman]

From: Rik van Riel <riel@redhat.com>

When suffering from memory fragmentation due to unfreeable pages,
THP page faults will repeatedly try to compact memory.  Due to the
unfreeable pages, compaction fails.

Needless to say, at that point page reclaim also fails to create
free contiguous 2MB areas.  However, that doesn't stop the current
code from trying, over and over again, and freeing a minimum of 4MB
(2UL << sc->order pages) at every single invocation.

This resulted in my 12GB system having 2-3GB free memory, a
corresponding amount of used swap and very sluggish response times.

This can be avoided by having the direct reclaim code not reclaim from
zones that already have plenty of free memory available for compaction.

If compaction still fails due to unmovable memory, doing additional
reclaim will only hurt the system, not help.

Signed-off-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Mel Gorman <mgorman@suse.de>
---
 mm/vmscan.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index b55699c..3817fa9 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2066,6 +2066,16 @@ static void shrink_zones(int priority, struct zonelist *zonelist,
 				continue;
 			if (zone->all_unreclaimable && priority != DEF_PRIORITY)
 				continue;	/* Let kswapd poll it */
+			if (COMPACTION_BUILD) {
+				/*
+				 * If we already have plenty of memory free
+				 * for compaction, don't free any more.
+				 */
+				if (sc->order > PAGE_ALLOC_COSTLY_ORDER &&
+					(compaction_suitable(zone, sc->order) ||
+					 compaction_deferred(zone)))
+					continue;
+			}
 			/*
 			 * This steals pages from memory cgroups over softlimit
 			 * and returns the number of reclaimed pages and
-- 
1.7.3.4

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 2/2] mm: Abort reclaim/compaction if compaction can proceed

[Mel Gorman]

If compaction can proceed, shrink_zones() stops doing any work but
the callers still shrink_slab(), raises the priority and potentially
sleeps.  This patch aborts direct reclaim/compaction entirely if
compaction can proceed.

Signed-off-by: Mel Gorman <mgorman@suse.de>
---
 mm/vmscan.c |   20 ++++++++++++++++----
 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 3817fa9..522f205 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2044,14 +2044,19 @@ restart:
  *
  * If a zone is deemed to be full of pinned pages then just give it a light
  * scan then give up on it.
+ *
+ * This function returns true if a zone is being reclaimed for a costly
+ * high-order allocation and compaction is either ready to begin or deferred.
+ * This indicates to the caller that it should retry the allocation or fail.
  */
-static void shrink_zones(int priority, struct zonelist *zonelist,
+static bool shrink_zones(int priority, struct zonelist *zonelist,
 					struct scan_control *sc)
 {
 	struct zoneref *z;
 	struct zone *zone;
 	unsigned long nr_soft_reclaimed;
 	unsigned long nr_soft_scanned;
+	bool should_abort_reclaim = false;
 
 	for_each_zone_zonelist_nodemask(zone, z, zonelist,
 					gfp_zone(sc->gfp_mask), sc->nodemask) {
@@ -2069,12 +2074,15 @@ static void shrink_zones(int priority, struct zonelist *zonelist,
 			if (COMPACTION_BUILD) {
 				/*
 				 * If we already have plenty of memory free
-				 * for compaction, don't free any more.
+				 * for compaction in this zone , don't free any
+				 * more.
 				 */
 				if (sc->order > PAGE_ALLOC_COSTLY_ORDER &&
 					(compaction_suitable(zone, sc->order) ||
-					 compaction_deferred(zone)))
+					 compaction_deferred(zone))) {
+					should_abort_reclaim = true;
 					continue;
+				}
 			}
 			/*
 			 * This steals pages from memory cgroups over softlimit
@@ -2093,6 +2101,8 @@ static void shrink_zones(int priority, struct zonelist *zonelist,
 
 		shrink_zone(priority, zone, sc);
 	}
+
+	return should_abort_reclaim;
 }
 
 static bool zone_reclaimable(struct zone *zone)
@@ -2157,7 +2167,9 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist,
 		sc->nr_scanned = 0;
 		if (!priority)
 			disable_swap_token(sc->mem_cgroup);
-		shrink_zones(priority, zonelist, sc);
+		if (shrink_zones(priority, zonelist, sc))
+			break;
+
 		/*
 		 * Don't shrink slabs when reclaiming memory from
 		 * over limit cgroups
-- 
1.7.3.4

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 1/2] mm: vmscan: Limit direct reclaim for higher order allocations

[Rik van Riel]

On 10/07/2011 11:17 AM, Mel Gorman wrote:
> From: Rik van Riel<riel@redhat.com>
>
> When suffering from memory fragmentation due to unfreeable pages,
> THP page faults will repeatedly try to compact memory.  Due to the
> unfreeable pages, compaction fails.

I believe Andrew just merged this one :)

-- 
All rights reversed

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 2/2] mm: Abort reclaim/compaction if compaction can proceed

[Rik van Riel]

On 10/07/2011 11:17 AM, Mel Gorman wrote:
> If compaction can proceed, shrink_zones() stops doing any work but
> the callers still shrink_slab(), raises the priority and potentially
> sleeps.  This patch aborts direct reclaim/compaction entirely if
> compaction can proceed.
>
> Signed-off-by: Mel Gorman<mgorman@suse.de>

This patch makes sense to me, but I have not tested it like
the first one.

Mel, have you tested this patch?  Did you see any changed
behaviour vs. just the first patch?

Having said that, I'm pretty sure the patch is ok :)

-- 
All rights reversed

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 1/2] mm: vmscan: Limit direct reclaim for higher order allocations

[Mel Gorman]

On Fri, Oct 07, 2011 at 03:32:29PM -0400, Rik van Riel wrote:
> On 10/07/2011 11:17 AM, Mel Gorman wrote:
> >From: Rik van Riel<riel@redhat.com>
> >
> >When suffering from memory fragmentation due to unfreeable pages,
> >THP page faults will repeatedly try to compact memory.  Due to the
> >unfreeable pages, compaction fails.
> 
> I believe Andrew just merged this one :)
> 

It's not the end of the world, this is not going to be the one mail that
bursts the inbox at the seams :)

-- 
Mel Gorman
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 2/2] mm: Abort reclaim/compaction if compaction can proceed

[Mel Gorman]

On Fri, Oct 07, 2011 at 04:07:06PM -0400, Rik van Riel wrote:
> On 10/07/2011 11:17 AM, Mel Gorman wrote:
> >If compaction can proceed, shrink_zones() stops doing any work but
> >the callers still shrink_slab(), raises the priority and potentially
> >sleeps.  This patch aborts direct reclaim/compaction entirely if
> >compaction can proceed.
> >
> >Signed-off-by: Mel Gorman<mgorman@suse.de>
> 
> This patch makes sense to me, but I have not tested it like
> the first one.
> 

Do if you can.

> Mel, have you tested this patch?

Yes.

> Did you see any changed
> behaviour vs. just the first patch?
> 

It's marginal and could be confirmation bias on my part. Basically,
there is noise when this path is being exercised but there were fewer
slabs scanned.  However, I don't know what the variances are and
whether the reduction was within the noise or not but it makes sense
that it would scan less.  If I profiled carefully, I might be able
to show that a few additional cycles are spent raising the priority
but it would be marginal.

While patch 1 is very clear, patch 2 depends on reviewers deciding it
"makes sense".

> Having said that, I'm pretty sure the patch is ok :)
> 

Care to ack?

-- 
Mel Gorman
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 2/2] mm: Abort reclaim/compaction if compaction can proceed

[Rik van Riel]

On 10/07/2011 04:24 PM, Mel Gorman wrote:
> On Fri, Oct 07, 2011 at 04:07:06PM -0400, Rik van Riel wrote:
>> On 10/07/2011 11:17 AM, Mel Gorman wrote:
>>> If compaction can proceed, shrink_zones() stops doing any work but
>>> the callers still shrink_slab(), raises the priority and potentially
>>> sleeps.  This patch aborts direct reclaim/compaction entirely if
>>> compaction can proceed.
>>>
>>> Signed-off-by: Mel Gorman<mgorman@suse.de>
>>
>> This patch makes sense to me, but I have not tested it like
>> the first one.
>>
>
> Do if you can.

I'll probably build a kernel with your patch in it on
Sunday - I'll be walking across a mountain tomorrow :)

> It's marginal and could be confirmation bias on my part. Basically,
> there is noise when this path is being exercised but there were fewer
> slabs scanned.  However, I don't know what the variances are and
> whether the reduction was within the noise or not but it makes sense
> that it would scan less.  If I profiled carefully, I might be able
> to show that a few additional cycles are spent raising the priority
> but it would be marginal.

This seems clear enough.

> While patch 1 is very clear, patch 2 depends on reviewers deciding it
> "makes sense".
>
>> Having said that, I'm pretty sure the patch is ok :)
>>
>
> Care to ack?

Sure.

Acked-by: Rik van Riel <riel@redhat.com>


-- 
All rights reversed

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 1/2] mm: vmscan: Limit direct reclaim for higher order allocations

[Minchan Kim]

On Fri, Oct 07, 2011 at 04:17:22PM +0100, Mel Gorman wrote:
> From: Rik van Riel <riel@redhat.com>
> 
> When suffering from memory fragmentation due to unfreeable pages,
> THP page faults will repeatedly try to compact memory.  Due to the
> unfreeable pages, compaction fails.
> 
> Needless to say, at that point page reclaim also fails to create
> free contiguous 2MB areas.  However, that doesn't stop the current
> code from trying, over and over again, and freeing a minimum of 4MB
> (2UL << sc->order pages) at every single invocation.
> 
> This resulted in my 12GB system having 2-3GB free memory, a
> corresponding amount of used swap and very sluggish response times.
> 
> This can be avoided by having the direct reclaim code not reclaim from
> zones that already have plenty of free memory available for compaction.
> 
> If compaction still fails due to unmovable memory, doing additional
> reclaim will only hurt the system, not help.
> 
> Signed-off-by: Rik van Riel <riel@redhat.com>
> Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>

-- 
Kinds regards,
Minchan Kim

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 2/2] mm: Abort reclaim/compaction if compaction can proceed

[Minchan Kim]

On Fri, Oct 07, 2011 at 04:17:23PM +0100, Mel Gorman wrote:
> If compaction can proceed, shrink_zones() stops doing any work but
> the callers still shrink_slab(), raises the priority and potentially
> sleeps.  This patch aborts direct reclaim/compaction entirely if
> compaction can proceed.
> 
> Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>

-- 
Kinds regards,
Minchan Kim

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 2/2] mm: Abort reclaim/compaction if compaction can proceed

[Johannes Weiner]

On Fri, Oct 07, 2011 at 04:17:23PM +0100, Mel Gorman wrote:
> If compaction can proceed, shrink_zones() stops doing any work but
> the callers still shrink_slab(), raises the priority and potentially
> sleeps.  This patch aborts direct reclaim/compaction entirely if
> compaction can proceed.
> 
> Signed-off-by: Mel Gorman <mgorman@suse.de>

Acked-by: Johannes Weiner <jweiner@redhat.com>

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>