linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Arcangeli <aarcange@redhat.com>
To: David Rientjes <rientjes@google.com>
Cc: Mel Gorman <mgorman@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Minchan Kim <minchan.kim@gmail.com>, Jan Kara <jack@suse.cz>,
	Andy Isaacson <adi@hexapodia.org>,
	Johannes Weiner <jweiner@redhat.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm: Do not stall in synchronous compaction for THP allocations
Date: Fri, 18 Nov 2011 18:59:23 +0100	[thread overview]
Message-ID: <20111118175923.GD3579@redhat.com> (raw)
In-Reply-To: <20111116133056.GC3306@redhat.com>

On Wed, Nov 16, 2011 at 02:30:56PM +0100, Andrea Arcangeli wrote:
> On Wed, Nov 16, 2011 at 05:13:50AM +0100, Andrea Arcangeli wrote:
> > After checking my current thp vmstat I think Andrew was right and we
> > backed out for a good reason before. I'm getting significantly worse
> > success rate, not sure why it was a small reduction in success rate
> > but hey I cannot exclude I may have broke something with some other
> > patch. I've been running it together with a couple more changes. If
> > it's this change that reduced the success rate, I'm afraid going
> > always async is not ok.
> 
> I wonder if the high failure rate when shutting off "sync compaction"
> and forcing only "async compaction" for THP (your patch queued in -mm)
> is also because of ISOLATE_CLEAN being set in compaction from commit
> 39deaf8. ISOLATE_CLEAN skipping PageDirty means all tmpfs/anon pages

I think I tracked down the source of the thp allocation
regression. They're commit e0887c19b2daa140f20ca8104bdc5740f39dbb86
and e0c23279c9f800c403f37511484d9014ac83adec. They're also wrong
because compaction_suitable doesn't check that there is enough free
memory in the number of "movable" pageblocks.

I'm going to test this not sure if it helps. But the more free memory
the more likely compaction succeeds, so there's still a risk we're
reducing the compaction success.

With the two commits above reverted my compaction success rate returns
near 100%, with the two commits above applied it goes to <50%... Now
we'll see what happens with the below patch.

===
From: Andrea Arcangeli <aarcange@redhat.com>
Subject: [PATCH] compaction: correct reverse check for compaction_deferred

Otherwise when compaction is deferred, reclaim stops to, leading to
high failure rate of high order allocations.

Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
---
 mm/vmscan.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index f7f7677..ce745f0 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2144,8 +2144,8 @@ static bool shrink_zones(int priority, struct zonelist *zonelist,
 				 * allocations.
 				 */
 				if (sc->order > PAGE_ALLOC_COSTLY_ORDER &&
-					(compaction_suitable(zone, sc->order) ||
-					 compaction_deferred(zone))) {
+				    (compaction_suitable(zone, sc->order) &&
+				     !compaction_deferred(zone))) {
 					should_abort_reclaim = true;
 					continue;
 				}

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

  parent reply	other threads:[~2011-11-18 17:59 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-10 10:06 [PATCH] mm: Do not stall in synchronous compaction for THP allocations Mel Gorman
2011-11-10 10:38 ` Johannes Weiner
2011-11-10 10:51 ` Alan Cox
2011-11-10 12:06   ` Johannes Weiner
2011-11-10 14:00 ` Andrea Arcangeli
2011-11-10 14:22 ` Mel Gorman
2011-11-10 15:12   ` Minchan Kim
2011-11-10 16:13     ` Mel Gorman
2011-11-10 16:30       ` Minchan Kim
2011-11-10 16:48         ` Mel Gorman
2011-11-10 23:12       ` Andrew Morton
2011-11-10 23:37         ` David Rientjes
2011-11-11 10:14           ` Mel Gorman
2011-11-11 10:39             ` David Rientjes
2011-11-11 11:17               ` Mel Gorman
2011-11-11 14:21               ` Andrea Arcangeli
2011-11-14 23:44             ` Andrew Morton
2011-11-15 13:25               ` Mel Gorman
2011-11-15 21:07                 ` David Rientjes
2011-11-15 23:48                   ` Mel Gorman
2011-11-16  0:07                     ` David Rientjes
2011-11-16  4:13                       ` Andrea Arcangeli
2011-11-16 13:30                         ` Andrea Arcangeli
2011-11-16 15:07                           ` Mel Gorman
2011-11-18 17:59                           ` Andrea Arcangeli [this message]
2011-11-16 14:14                         ` Mel Gorman
2011-11-11 10:01         ` Mel Gorman
2011-11-15  0:03           ` Andrew Morton
2011-11-15  2:00             ` Andrea Arcangeli
2011-11-15  2:08               ` Andrea Arcangeli
2011-11-15 15:01                 ` Mel Gorman
2011-11-15 15:00               ` Mel Gorman
2011-11-15 13:07             ` Mel Gorman
2011-11-15 15:47               ` Andrea Arcangeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111118175923.GD3579@redhat.com \
    --to=aarcange@redhat.com \
    --cc=adi@hexapodia.org \
    --cc=akpm@linux-foundation.org \
    --cc=jack@suse.cz \
    --cc=jweiner@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=minchan.kim@gmail.com \
    --cc=rientjes@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).