All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yang Shi <shy828301@gmail.com>
To: guro@fb.com, ktkhai@virtuozzo.com, vbabka@suse.cz,
	shakeelb@google.com, david@fromorbit.com, hannes@cmpxchg.org,
	mhocko@suse.com, akpm@linux-foundation.org
Cc: shy828301@gmail.com, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [v8 PATCH 13/13] mm: vmscan: shrink deferred objects proportional to priority
Date: Tue, 16 Feb 2021 16:13:22 -0800	[thread overview]
Message-ID: <20210217001322.2226796-14-shy828301@gmail.com> (raw)
In-Reply-To: <20210217001322.2226796-1-shy828301@gmail.com>

The number of deferred objects might get windup to an absurd number, and it
results in clamp of slab objects.  It is undesirable for sustaining workingset.

So shrink deferred objects proportional to priority and cap nr_deferred to twice
of cache items.

The idea is borrowed from Dave Chinner's patch:
https://lore.kernel.org/linux-xfs/20191031234618.15403-13-david@fromorbit.com/

Tested with kernel build and vfs metadata heavy workload in our production
environment, no regression is spotted so far.

Signed-off-by: Yang Shi <shy828301@gmail.com>
---
 mm/vmscan.c | 46 +++++++++++-----------------------------------
 1 file changed, 11 insertions(+), 35 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 4247a3568585..b3bdc3ba8edc 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -661,7 +661,6 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl,
 	 */
 	nr = xchg_nr_deferred(shrinker, shrinkctl);
 
-	total_scan = nr;
 	if (shrinker->seeks) {
 		delta = freeable >> priority;
 		delta *= 4;
@@ -675,37 +674,9 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl,
 		delta = freeable / 2;
 	}
 
+	total_scan = nr >> priority;
 	total_scan += delta;
-	if (total_scan < 0) {
-		pr_err("shrink_slab: %pS negative objects to delete nr=%ld\n",
-		       shrinker->scan_objects, total_scan);
-		total_scan = freeable;
-		next_deferred = nr;
-	} else
-		next_deferred = total_scan;
-
-	/*
-	 * We need to avoid excessive windup on filesystem shrinkers
-	 * due to large numbers of GFP_NOFS allocations causing the
-	 * shrinkers to return -1 all the time. This results in a large
-	 * nr being built up so when a shrink that can do some work
-	 * comes along it empties the entire cache due to nr >>>
-	 * freeable. This is bad for sustaining a working set in
-	 * memory.
-	 *
-	 * Hence only allow the shrinker to scan the entire cache when
-	 * a large delta change is calculated directly.
-	 */
-	if (delta < freeable / 4)
-		total_scan = min(total_scan, freeable / 2);
-
-	/*
-	 * Avoid risking looping forever due to too large nr value:
-	 * never try to free more than twice the estimate number of
-	 * freeable entries.
-	 */
-	if (total_scan > freeable * 2)
-		total_scan = freeable * 2;
+	total_scan = min(total_scan, (2 * freeable));
 
 	trace_mm_shrink_slab_start(shrinker, shrinkctl, nr,
 				   freeable, delta, total_scan, priority);
@@ -744,10 +715,15 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl,
 		cond_resched();
 	}
 
-	if (next_deferred >= scanned)
-		next_deferred -= scanned;
-	else
-		next_deferred = 0;
+	/*
+	 * The deferred work is increased by any new work (delta) that wasn't
+	 * done, decreased by old deferred work that was done now.
+	 *
+	 * And it is capped to two times of the freeable items.
+	 */
+	next_deferred = max_t(long, (nr + delta - scanned), 0);
+	next_deferred = min(next_deferred, (2 * freeable));
+
 	/*
 	 * move the unused scan count back into the shrinker in a
 	 * manner that handles concurrent updates.
-- 
2.26.2


  parent reply	other threads:[~2021-02-17  0:19 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-17  0:13 [v8 PATCH 00/13] Make shrinker's nr_deferred memcg aware Yang Shi
2021-02-17  0:13 ` [v8 PATCH 01/13] mm: vmscan: use nid from shrink_control for tracepoint Yang Shi
2021-02-17  0:13 ` [v8 PATCH 02/13] mm: vmscan: consolidate shrinker_maps handling code Yang Shi
2021-02-17  0:13 ` [v8 PATCH 03/13] mm: vmscan: use shrinker_rwsem to protect shrinker_maps allocation Yang Shi
2021-03-08  6:40   ` Shakeel Butt
2021-03-08  6:40     ` Shakeel Butt
2021-02-17  0:13 ` [v8 PATCH 04/13] mm: vmscan: remove memcg_shrinker_map_size Yang Shi
2021-03-08  6:49   ` Shakeel Butt
2021-03-08  6:49     ` Shakeel Butt
2021-02-17  0:13 ` [v8 PATCH 05/13] mm: vmscan: use kvfree_rcu instead of call_rcu Yang Shi
2021-02-17  1:59   ` Roman Gushchin
2021-02-17  6:25   ` Kirill Tkhai
2021-03-08  6:13   ` Shakeel Butt
2021-03-08  6:13     ` Shakeel Butt
2021-03-08 14:54     ` Paul E. McKenney
2021-03-08 18:15       ` Yang Shi
2021-03-08 18:15         ` Yang Shi
2021-03-08 16:49     ` Roman Gushchin
2021-03-08 20:22       ` Yang Shi
2021-03-08 20:22         ` Yang Shi
2021-03-08 21:11         ` Shakeel Butt
2021-03-08 21:11           ` Shakeel Butt
2021-02-17  0:13 ` [v8 PATCH 06/13] mm: memcontrol: rename shrinker_map to shrinker_info Yang Shi
2021-03-08  6:50   ` Shakeel Butt
2021-03-08  6:50     ` Shakeel Butt
2021-02-17  0:13 ` [v8 PATCH 07/13] mm: vmscan: add shrinker_info_protected() helper Yang Shi
2021-03-08  6:52   ` Shakeel Butt
2021-03-08  6:52     ` Shakeel Butt
2021-02-17  0:13 ` [v8 PATCH 08/13] mm: vmscan: use a new flag to indicate shrinker is registered Yang Shi
2021-02-17  2:00   ` Roman Gushchin
2021-03-08 17:48   ` Shakeel Butt
2021-03-08 17:48     ` Shakeel Butt
2021-02-17  0:13 ` [v8 PATCH 09/13] mm: vmscan: add per memcg shrinker nr_deferred Yang Shi
2021-02-17  2:09   ` Roman Gushchin
2021-02-17  6:34   ` Kirill Tkhai
2021-03-08 19:12   ` Shakeel Butt
2021-03-08 19:12     ` Shakeel Butt
2021-03-08 20:30     ` Yang Shi
2021-03-08 20:30       ` Yang Shi
2021-03-08 21:11       ` Shakeel Butt
2021-03-08 21:11         ` Shakeel Butt
2021-02-17  0:13 ` [v8 PATCH 10/13] mm: vmscan: use per memcg nr_deferred of shrinker Yang Shi
2021-02-17  2:10   ` Roman Gushchin
2021-02-17  6:39   ` Kirill Tkhai
2021-03-08 19:14   ` Shakeel Butt
2021-03-08 19:14     ` Shakeel Butt
2021-02-17  0:13 ` [v8 PATCH 11/13] mm: vmscan: don't need allocate shrinker->nr_deferred for memcg aware shrinkers Yang Shi
2021-03-08 21:57   ` Shakeel Butt
2021-03-08 21:57     ` Shakeel Butt
2021-02-17  0:13 ` [v8 PATCH 12/13] mm: memcontrol: reparent nr_deferred when memcg offline Yang Shi
2021-03-08 23:42   ` Shakeel Butt
2021-03-08 23:42     ` Shakeel Butt
2021-02-17  0:13 ` Yang Shi [this message]
2021-02-25 17:00 ` [v8 PATCH 00/13] Make shrinker's nr_deferred memcg aware Yang Shi
2021-02-25 17:00   ` Yang Shi
2021-03-01 15:05   ` Johannes Weiner
2021-03-01 17:03     ` Yang Shi
2021-03-01 17:03       ` Yang Shi

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=20210217001322.2226796-14-shy828301@gmail.com \
    --to=shy828301@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@fromorbit.com \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=ktkhai@virtuozzo.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=shakeelb@google.com \
    --cc=vbabka@suse.cz \
    /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.