linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: George Spelvin <linux@horizon.com>
Cc: dave@linux.vnet.ibm.com, jack@suse.cz,
	Rik van Riel <riel@redhat.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: 3.7-rc6 soft lockup in kswapd0
Date: Mon, 26 Nov 2012 10:01:02 +0000	[thread overview]
Message-ID: <20121126100102.GH8218@suse.de> (raw)
In-Reply-To: <20121126035841.5973.qmail@science.horizon.com>

On Sun, Nov 25, 2012 at 10:58:41PM -0500, George Spelvin wrote:
> Sorry for the delay; was AF(that)K for the weekend.
> 
> > Ok, is there any chance you can capture more of sysrq+m, particularly the
> > bits that say how much free memory there is and many pages of each order
> > that is free? If you can't, it's ok. I ask because my kernel bug dowsing
> > rod is twitching in the direction of the recent free page accounting bug
> > Dave Hansen identified and fixed -- https://lkml.org/lkml/2012/11/21/504
> 
> Okay; as mentioned, I installed that patch and it didn't make any obvious
> difference to the symptoms.
> 
> The hang IP is still either in __zone_watermark_ok or kswapd (address varies).
> 

Ok, can you try this patch from Rik on top as well please? This is in
addition to Dave Hansen's accounting fix.

---8<---
From: Rik van Riel <riel@redhat.com>
Subject: mm,vmscan: only loop back if compaction would fail in all zones

Kswapd frees memory to satisfy two goals:
1) allow allocations to succeed, and
2) balance memory pressure between zones 

Currently, kswapd has an issue where it will loop back to free
more memory if any memory zone in the pgdat has not enough free
memory for compaction.  This can lead to unnecessary overhead,
and even infinite loops in kswapd.

It is better to only loop back to free more memory if all of
the zones in the pgdat have insufficient free memory for
compaction.  That satisfies both of kswapd's goals with less
overhead.

Signed-off-by: Rik van Riel <riel@redhat.com>
---
 mm/vmscan.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index b99ecba..f0d111b 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2790,6 +2790,7 @@ static unsigned long balance_pgdat(pg_data_t *pgdat, int order,
 	 */
 	if (order) {
 		int zones_need_compaction = 1;
+		int compaction_needs_memory = 1;
 
 		for (i = 0; i <= end_zone; i++) {
 			struct zone *zone = pgdat->node_zones + i;
@@ -2801,10 +2802,10 @@ static unsigned long balance_pgdat(pg_data_t *pgdat, int order,
 			    sc.priority != DEF_PRIORITY)
 				continue;
 
-			/* Would compaction fail due to lack of free memory? */
+			/* Is there enough memory for compaction? */
 			if (COMPACTION_BUILD &&
-			    compaction_suitable(zone, order) == COMPACT_SKIPPED)
-				goto loop_again;
+			    compaction_suitable(zone, order) != COMPACT_SKIPPED)
+				compaction_needs_memory = 0;
 
 			/* Confirm the zone is balanced for order-0 */
 			if (!zone_watermark_ok(zone, 0,
@@ -2822,6 +2823,10 @@ static unsigned long balance_pgdat(pg_data_t *pgdat, int order,
 			zone_clear_flag(zone, ZONE_CONGESTED);
 		}
 
+		/* None of the zones had enough free memory for compaction. */
+		if (compaction_needs_memory)
+			goto loop_again;
+
 		if (zones_need_compaction)
 			compact_pgdat(pgdat, order);
 	}

  reply	other threads:[~2012-11-26 10:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-22 17:58 3.7-rc6 soft lockup in kswapd0 George Spelvin
2012-11-22 22:06 ` Jan Kara
2012-11-22 22:36   ` Jan Kara
2012-11-23  8:51   ` Mel Gorman
2012-11-23 10:02     ` George Spelvin
2012-11-24  7:52       ` George Spelvin
2012-11-26  3:58     ` George Spelvin
2012-11-26 10:01       ` Mel Gorman [this message]
2012-11-26 13:05         ` George Spelvin
2012-11-26 18:32           ` Johannes Weiner
2012-11-26 18:53             ` George Spelvin
2012-11-26 19:09               ` Mel Gorman
2012-11-27 21:25                 ` George Spelvin
2012-11-28 11:39                   ` Mel Gorman
2012-11-29 14:54                     ` George Spelvin
2012-11-29 15:20                       ` Mel Gorman
2012-11-29 17:08                       ` Johannes Weiner
2012-12-03 18:28                       ` George Spelvin

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=20121126100102.GH8218@suse.de \
    --to=mgorman@suse.de \
    --cc=dave@linux.vnet.ibm.com \
    --cc=hannes@cmpxchg.org \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@horizon.com \
    --cc=riel@redhat.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).