mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Trevor Cordes <trevor@tecnopolis.ca>
Cc: Michal Hocko <mhocko@kernel.org>,
	linux-kernel@vger.kernel.org,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Minchan Kim <minchan@kernel.org>, Rik van Riel <riel@surriel.com>,
	Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Subject: Re: mm, vmscan: commit makes PAE kernel crash nightly (bisected)
Date: Fri, 20 Jan 2017 15:55:53 +0000	[thread overview]
Message-ID: <20170120155553.gjv2x5eycvdudnil@techsingularity.net> (raw)
In-Reply-To: <20170120110232.y7xd4b7wtwqslgnw@techsingularity.net>

On Fri, Jan 20, 2017 at 11:02:32AM +0000, Mel Gorman wrote:
> On Fri, Jan 20, 2017 at 12:35:44AM -0600, Trevor Cordes wrote:
> > > > Hi!  The git tree above version oom'd after < 24 hours (3:02am) so
> > > > it doesn't solve the bug.  If you need a oom messages dump let me
> > > > know.  
> > > 
> > > Yes please.
> > 
> > The first oom from that night attached.  Note, the oom wasn't as dire
> > with your mhocko/4.9.0+ as it usually is with stock 4.8.x: my oom
> > detector and reboot script was able to do its thing cleanly before the
> > system became unusable.
> > 
> > I'll await further instructions and test right away.  Maybe I'll try a
> > few tuning ideas until then.  Thanks!
> > 
> 
> Thanks for the OOM report. I was expecting it to be a particular shape and
> my expectations were not matched so it took time to consider it further. Can
> you try the cumulative patch below? It combines three patches that
> 
> 1. Allow slab shrinking even if the LRU patches are unreclaimable in
>    direct reclaim
> 2. Shrinks slab based once based on the contents of all memcgs instead
>    of shrinking one at a time
> 3. Tries to shrink slabs if the lowmem usage is too high
> 
> Unfortunately it's only boot tested on x86-64 as I didn't get the chance
> to setup an i386 test bed.
> 

There was one major flaw in that patch. This version fixes it and
addresses other minor issues. It may still be too agressive shrinking
slab but worth trying out. Thanks.

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 2281ad310d06..2c735ea24a85 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2318,6 +2318,59 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg,
 	}
 }
 
+#ifdef CONFIG_HIGHMEM
+static void balance_slab_lowmem(struct pglist_data *pgdat,
+				struct scan_control *sc)
+{
+	unsigned long lru_pages = 0;
+	unsigned long slab_pages = 0;
+	unsigned long managed_pages = 0;
+	int zid;
+
+	for (zid = 0; zid < MAX_NR_ZONES; zid++) {
+		struct zone *zone = &pgdat->node_zones[zid];
+
+		if (!populated_zone(zone) || is_highmem_idx(zid))
+			continue;
+
+		lru_pages += zone_page_state(zone, NR_ZONE_INACTIVE_FILE);
+		lru_pages += zone_page_state(zone, NR_ZONE_ACTIVE_FILE);
+		lru_pages += zone_page_state(zone, NR_ZONE_INACTIVE_ANON);
+		lru_pages += zone_page_state(zone, NR_ZONE_ACTIVE_ANON);
+		slab_pages += zone_page_state(zone, NR_SLAB_RECLAIMABLE);
+		slab_pages += zone_page_state(zone, NR_SLAB_UNRECLAIMABLE);
+	}
+
+	/* Do not balance until LRU and slab exceeds 50% of lowmem */
+	if (lru_pages + slab_pages < (managed_pages >> 1))
+		return;
+
+	/*
+	 * Shrink reclaimable slabs if the number of lowmem slab pages is
+	 * over twice the size of LRU pages. Apply pressure relative to
+	 * the imbalance between LRU and slab pages.
+	 */
+	if (slab_pages > lru_pages << 1) {
+		struct reclaim_state *reclaim_state = current->reclaim_state;
+		unsigned long exceed = slab_pages - (lru_pages << 1);
+		int nid = pgdat->node_id;
+
+		exceed = min(exceed, slab_pages);
+		shrink_slab(sc->gfp_mask, nid, NULL, exceed >> 3, slab_pages);
+		if (reclaim_state) {
+			sc->nr_reclaimed += reclaim_state->reclaimed_slab;
+			reclaim_state->reclaimed_slab = 0;
+		}
+	}
+}
+#else
+static void balance_slab_lowmem(struct pglist_data *pgdat,
+				struct scan_control *sc)
+{
+	return;
+}
+#endif
+
 /*
  * This is a basic per-node page freer.  Used by both kswapd and direct reclaim.
  */
@@ -2336,6 +2389,27 @@ static void shrink_node_memcg(struct pglist_data *pgdat, struct mem_cgroup *memc
 
 	get_scan_count(lruvec, memcg, sc, nr, lru_pages);
 
+	/*
+	 * If direct reclaiming at elevated priority and the node is
+	 * unreclaimable then skip LRU reclaim and let kswapd poll it.
+	 */
+	if (!current_is_kswapd() &&
+	    sc->priority != DEF_PRIORITY &&
+	    !pgdat_reclaimable(pgdat)) {
+		unsigned long nr_scanned;
+
+		/*
+		 * Fake scanning so that slab shrinking will continue. For
+		 * lowmem restricted allocations, shrink aggressively.
+		 */
+		nr_scanned = SWAP_CLUSTER_MAX << (DEF_PRIORITY - sc->priority);
+		if (!(sc->gfp_mask & __GFP_HIGHMEM))
+			nr_scanned = max(nr_scanned, *lru_pages);
+		sc->nr_scanned += nr_scanned;
+
+		return;
+	}
+
 	/* Record the original scan target for proportional adjustments later */
 	memcpy(targets, nr, sizeof(nr));
 
@@ -2435,6 +2509,8 @@ static void shrink_node_memcg(struct pglist_data *pgdat, struct mem_cgroup *memc
 	if (inactive_list_is_low(lruvec, false, sc, true))
 		shrink_active_list(SWAP_CLUSTER_MAX, lruvec,
 				   sc, LRU_ACTIVE_ANON);
+
+	balance_slab_lowmem(pgdat, sc);
 }
 
 /* Use reclaim/compaction for costly allocs or under memory pressure */
@@ -2533,7 +2609,8 @@ static bool shrink_node(pg_data_t *pgdat, struct scan_control *sc)
 			.pgdat = pgdat,
 			.priority = sc->priority,
 		};
-		unsigned long node_lru_pages = 0;
+		unsigned long slab_pressure = 0;
+		unsigned long slab_eligible = 0;
 		struct mem_cgroup *memcg;
 
 		nr_reclaimed = sc->nr_reclaimed;
@@ -2555,12 +2632,8 @@ static bool shrink_node(pg_data_t *pgdat, struct scan_control *sc)
 			scanned = sc->nr_scanned;
 
 			shrink_node_memcg(pgdat, memcg, sc, &lru_pages);
-			node_lru_pages += lru_pages;
-
-			if (memcg)
-				shrink_slab(sc->gfp_mask, pgdat->node_id,
-					    memcg, sc->nr_scanned - scanned,
-					    lru_pages);
+			slab_eligible += lru_pages;
+			slab_pressure += sc->nr_reclaimed - reclaimed;
 
 			/* Record the group's reclaim efficiency */
 			vmpressure(sc->gfp_mask, memcg, false,
@@ -2586,12 +2659,12 @@ static bool shrink_node(pg_data_t *pgdat, struct scan_control *sc)
 
 		/*
 		 * Shrink the slab caches in the same proportion that
-		 * the eligible LRU pages were scanned.
+		 * the eligible LRU pages were scanned. For memcg, this
+		 * will apply the cumulative scanning pressure over all
+		 * memcgs.
 		 */
-		if (global_reclaim(sc))
-			shrink_slab(sc->gfp_mask, pgdat->node_id, NULL,
-				    sc->nr_scanned - nr_scanned,
-				    node_lru_pages);
+		shrink_slab(sc->gfp_mask, pgdat->node_id, NULL, slab_pressure,
+							slab_eligible);
 
 		if (reclaim_state) {
 			sc->nr_reclaimed += reclaim_state->reclaimed_slab;
@@ -2683,10 +2756,6 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc)
 						 GFP_KERNEL | __GFP_HARDWALL))
 				continue;
 
-			if (sc->priority != DEF_PRIORITY &&
-			    !pgdat_reclaimable(zone->zone_pgdat))
-				continue;	/* Let kswapd poll it */
-
 			/*
 			 * If we already have plenty of memory free for
 			 * compaction in this zone, don't free any more.
-- 
Mel Gorman
SUSE Labs

  reply	other threads:[~2017-01-20 15:56 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-11 10:32 Trevor Cordes
2017-01-11 12:11 ` Mel Gorman
2017-01-11 12:14   ` Mel Gorman
2017-01-11 22:52     ` Trevor Cordes
2017-01-12  9:36       ` Michal Hocko
2017-01-15  6:27         ` Trevor Cordes
2017-01-16 11:09           ` Mel Gorman
2017-01-17 13:52             ` Michal Hocko
2017-01-17 14:21               ` Mel Gorman
2017-01-17 14:54                 ` Michal Hocko
2017-01-18  7:25                   ` Trevor Cordes
2017-01-18 17:48                   ` Mel Gorman
2017-01-18 18:07                   ` Mel Gorman
2017-01-19  9:48                   ` Trevor Cordes
2017-01-19 11:37                     ` Michal Hocko
2017-01-20  6:35                       ` Trevor Cordes
2017-01-20 11:02                         ` Mel Gorman
2017-01-20 15:55                           ` Mel Gorman [this message]
2017-01-23  0:45                             ` Trevor Cordes
2017-01-23 10:48                               ` Mel Gorman
2017-01-23 11:04                                 ` Mel Gorman
2017-01-25  9:46                                   ` Michal Hocko
2017-01-24 12:59                                 ` Michal Hocko
2017-01-25 10:02                                 ` Trevor Cordes
2017-01-25 12:04                                   ` Michal Hocko
2017-01-29 22:50                                     ` Trevor Cordes
2017-01-30  7:51                                       ` Michal Hocko
2017-02-01  9:29                                         ` Trevor Cordes
2017-02-01 10:14                                           ` Michal Hocko
2017-02-04  0:36                                             ` Trevor Cordes
2017-02-04 20:05                                               ` Rik van Riel
2017-02-05 10:03                                               ` Michal Hocko
2017-02-05 22:53                                                 ` Trevor Cordes
2017-01-30  9:10                                       ` Mel Gorman
2017-01-24 12:54                               ` Michal Hocko
2017-01-26 23:18                                 ` Trevor Cordes
2017-01-27  7:36                                   ` Michal Hocko
2017-01-24 12:51                         ` Michal Hocko
2017-01-18  6:52             ` Trevor Cordes
2017-01-17 13:45           ` Michal Hocko

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=20170120155553.gjv2x5eycvdudnil@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@kernel.org \
    --cc=minchan@kernel.org \
    --cc=riel@surriel.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=trevor@tecnopolis.ca \
    /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

Powered by JetHome