All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Shaohua Li <shaohua.li@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>,
	"Chen, Tim C" <tim.c.chen@intel.com>,
	Rik van Riel <riel@redhat.com>,
	alex.shi@intel.com
Subject: Re: too big min_free_kbytes
Date: Tue, 22 Feb 2011 16:04:50 +0000	[thread overview]
Message-ID: <20110222160449.GF15652@csn.ul.ie> (raw)
In-Reply-To: <20110222144200.GY13092@random.random>

On Tue, Feb 22, 2011 at 03:42:00PM +0100, Andrea Arcangeli wrote:
> I suggest to boot with transparent_hugepage=madvise, or to set the
> default to madvise in make menuconfig. That will still enable the
> anti-frag logic in the buddy allocator in full. If the problem goes
> away with the madvise setting, then it's not related to
> min_free_kbytes. With the 700M fix for kswapd however it's hard to
> imagine the increase min_free_kbytes to cause out of memory conditions
> even if it uses a little more memory to allow for increased
> performance thanks to hugepages.
> 

We didn't really agree on a fix though, did we? At least, I don't see a
patch we all agreed on in the thread. I stuck my ack on your patch but Rik
nak'd it because he wanted the balance gap to be preserved. We had sortof
agreed on a balance gap but didn't post a patch that implemented it. AFAIK,
an implementation of what was discussed is blow. If this is not the agreed
fix, what is? If we agree on it, can Shaohua confirm the fix works?

This is against 2.6.38-rc6 which still isn't fixed and I don't see a
candidate fix in mmotm either.

==== CUT HERE ====
mm: vmscan: kswapd should not free an excessive number of pages when balancing small zones

When reclaiming for order-0 pages, kswapd requires that all zones be
balanced. Each cycle through balance_pgdat() does background ageing on all
zones if necessary and applies equal pressure on the inactive zone unless
a lot of pages are free already.

A "lot of free pages" is defined as a "balance gap" above the high watermark
which is currently 7*high_watermark. Historically this was reasonable as
min_free_kbytes was small. However, on systems using huge pages, it is
recommended that min_free_kbytes is higher and it is tuned with hugeadm
--set-recommended-min_free_kbytes. With the introduction of transparent
huge page support, this recommended value is also applied. On X86-64 with
4G of memory, min_free_kbytes becomes 67584 so one would expect around 68M
of memory to be free. The Normal zone is approximately 35000 pages so under
even normal memory pressure such as copying a large file, it gets exhausted
quickly. As it is getting exhausted, kswapd applies pressure equally to all
zones, including the DMA32 zone. DMA32 is approximately 700,000 pages with
a high watermark of around 23,000 pages. In this situation, kswapd will
reclaim around (23000*8 where 8 is the high watermark + balance gap of 7 *
high watermark) pages or 718M of pages before the zone is ignored. What
the user sees is that free memory far higher than it should be.

To avoid an excessive number of pages being reclaimed from the larger zones,
explicitely defines the "balance gap" to be either 1% of the zone or the
low watermark for the zone, whichever is smaller.  While kswapd will check
all zones to apply pressure, it'll ignore zones that meets the (high_wmark +
balance_gap) watermark.

To test this, 80G were copied from a partition and the amount of memory
being used was recorded. A comparison of a patch and unpatched kernel
can be seen at
http://www.csn.ul.ie/~mel/postings/minfree-20110222/memory-usage-hydra.ps
and shows that kswapd is not reclaiming as much memory with the patch
applied.

Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
---
 include/linux/swap.h |    9 +++++++++
 mm/vmscan.c          |   16 +++++++++++++---
 2 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index 4d55932..a57c6e7 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -155,6 +155,15 @@ enum {
 #define SWAP_CLUSTER_MAX 32
 #define COMPACT_CLUSTER_MAX SWAP_CLUSTER_MAX
 
+/*
+ * Ratio between the present memory in the zone and the "gap" that
+ * we're allowing kswapd to shrink in addition to the per-zone high
+ * wmark, even for zones that already have the high wmark satisfied,
+ * in order to provide better per-zone lru behavior. We are ok to
+ * spend not more than 1% of the memory for this zone balancing "gap".
+ */
+#define KSWAPD_ZONE_BALANCE_GAP_RATIO 100
+
 #define SWAP_MAP_MAX	0x3e	/* Max duplication count, in first swap_map */
 #define SWAP_MAP_BAD	0x3f	/* Note pageblock is bad, in first swap_map */
 #define SWAP_HAS_CACHE	0x40	/* Flag page is cached, in first swap_map */
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 17497d0..0c83530 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2388,6 +2388,7 @@ loop_again:
 			int compaction;
 			struct zone *zone = pgdat->node_zones + i;
 			int nr_slab;
+			unsigned long balance_gap;
 
 			if (!populated_zone(zone))
 				continue;
@@ -2404,11 +2405,20 @@ loop_again:
 			mem_cgroup_soft_limit_reclaim(zone, order, sc.gfp_mask);
 
 			/*
-			 * We put equal pressure on every zone, unless one
-			 * zone has way too many pages free already.
+			 * We put equal pressure on every zone, unless
+			 * one zone has way too many pages free
+			 * already. The "too many pages" is defined
+			 * as the high wmark plus a "gap" where the
+			 * gap is either the low watermark or 1%
+			 * of the zone, whichever is smaller.
 			 */
+			balance_gap = min(low_wmark_pages(zone),
+				(zone->present_pages +
+					KSWAPD_ZONE_BALANCE_GAP_RATIO-1) /
+				KSWAPD_ZONE_BALANCE_GAP_RATIO);
 			if (!zone_watermark_ok_safe(zone, order,
-					8*high_wmark_pages(zone), end_zone, 0))
+					high_wmark_pages(zone) + balance_gap,
+					end_zone, 0))
 				shrink_zone(priority, zone, &sc);
 			reclaim_state->reclaimed_slab = 0;
 			nr_slab = shrink_slab(sc.nr_scanned, GFP_KERNEL,

--
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-02-22 16:05 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-24  3:56 too big min_free_kbytes Shaohua Li
2011-01-24 15:00 ` Andrea Arcangeli
2011-01-25 14:35   ` Mel Gorman
2011-01-26 14:17   ` Mel Gorman
2011-01-26 15:23     ` Mel Gorman
2011-01-26 15:42       ` Andrea Arcangeli
2011-01-26 16:36         ` Mel Gorman
2011-01-26 17:42           ` Mel Gorman
2011-01-27 13:40             ` Mel Gorman
2011-01-27 15:27               ` Andrea Arcangeli
2011-01-27 16:03                 ` Mel Gorman
2011-01-27 18:52                   ` Andrea Arcangeli
2011-01-27 20:33                     ` Rik van Riel
2011-01-27 21:31                     ` Mel Gorman
2011-01-27 23:18                       ` Rik van Riel
2011-01-28 10:35                         ` Mel Gorman
2011-01-28 16:28                           ` Andrea Arcangeli
2011-01-28 16:46                             ` Mel Gorman
2011-01-28 17:16                               ` Rik van Riel
2011-01-28 17:46                                 ` Andrea Arcangeli
2011-01-28 18:03                                   ` Rik van Riel
2011-01-28 18:24                                     ` Andrea Arcangeli
2011-01-28 19:34                                       ` Rik van Riel
2011-01-28 19:45                                         ` Andrea Arcangeli
2011-01-28 20:55                                           ` Rik van Riel
2011-01-29 19:45                                             ` Andrea Arcangeli
2011-01-28 17:34                               ` Andrea Arcangeli
2011-01-28 17:10                             ` Rik van Riel
2011-02-03  2:58                 ` Andrea Arcangeli
2011-02-03 13:15                   ` Mel Gorman
2011-02-03 18:59                     ` Andrea Arcangeli
2011-02-03 14:36                   ` Rik van Riel
2011-02-03 19:11                     ` Andrea Arcangeli
2011-02-12  1:28                       ` Simon Kirby
2011-02-14  2:25                   ` Shaohua Li
2011-02-22 14:25                     ` Mel Gorman
2011-02-22 14:42                       ` Andrea Arcangeli
2011-02-22 14:50                         ` Mel Gorman
2011-02-22 14:54                           ` Andrea Arcangeli
2011-02-22 16:04                         ` Mel Gorman [this message]
2011-02-22 16:40                           ` Rik van Riel
2011-02-23  5:29                       ` Shaohua Li
2011-02-23 14:45                         ` Andrea Arcangeli
2011-02-24  8:08                           ` Shaohua Li
2011-02-24  9:52                             ` Mel Gorman
2011-02-24  9:57                               ` Mel Gorman
2011-02-24 14:27                                 ` Andrea Arcangeli
2011-02-24 14:04                             ` Andrea Arcangeli
2011-02-25  0:51                               ` Shaohua Li
2011-02-25 12:13                                 ` Mel Gorman
2011-02-12  9:48                 ` alex shi
2011-02-22 14:24                   ` Mel Gorman

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=20110222160449.GF15652@csn.ul.ie \
    --to=mel@csn.ul.ie \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.shi@intel.com \
    --cc=linux-mm@kvack.org \
    --cc=riel@redhat.com \
    --cc=shaohua.li@intel.com \
    --cc=tim.c.chen@intel.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 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.