From: Vladimir Davydov <vdavydov@parallels.com>
To: akpm@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
devel@openvz.org, Mel Gorman <mgorman@suse.de>,
Michal Hocko <mhocko@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>,
Rik van Riel <riel@redhat.com>,
Dave Chinner <dchinner@redhat.com>,
Glauber Costa <glommer@gmail.com>
Subject: [PATCH 3/3] mm: vmscan: shrink_slab: do not skip caches with < batch_size objects
Date: Fri, 17 Jan 2014 23:25:31 +0400 [thread overview]
Message-ID: <461628a5763b31bb36cc3dd7f6b89b06a907234f.1389982079.git.vdavydov@parallels.com> (raw)
In-Reply-To: <4e2efebe688e06574f6495c634ac45d799e1518d.1389982079.git.vdavydov@parallels.com>
In its current implementation, shrink_slab() won't scan caches that have
less than batch_size objects. If there are only a few shrinkers
available, such a behavior won't cause any problems, because the
batch_size is usually small, but if we have a lot of slab shrinkers,
which is perfectly possible since FS shrinkers are now per-superblock,
we can end up with hundreds of megabytes of practically unreclaimable
kmem objects. For instance, mounting a thousand of ext2 FS images with a
hundred of files in each and iterating over all the files using du(1)
will result in about 200 Mb of FS caches that cannot be dropped even
with the aid of the vm.drop_caches sysctl! Fix this.
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: Glauber Costa <glommer@gmail.com>
---
mm/vmscan.c | 25 +++++++++++++++++++------
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index f6d716d..2e710d4 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -275,7 +275,7 @@ shrink_slab_node(struct shrink_control *shrinkctl, struct shrinker *shrinker,
* a large delta change is calculated directly.
*/
if (delta < freeable / 4)
- total_scan = min(total_scan, freeable / 2);
+ total_scan = min(total_scan, max(freeable / 2, batch_size));
/*
* Avoid risking looping forever due to too large nr value:
@@ -289,21 +289,34 @@ shrink_slab_node(struct shrink_control *shrinkctl, struct shrinker *shrinker,
nr_pages_scanned, lru_pages,
freeable, delta, total_scan);
- while (total_scan >= batch_size) {
+ /*
+ * To avoid CPU cache thrashing, we should not scan less than
+ * batch_size objects in one pass, but if the cache has less
+ * than batch_size objects in total, and we really want to
+ * shrink them all, go ahead and scan what we have, otherwise
+ * last batch_size objects will never get reclaimed.
+ */
+ if (total_scan < batch_size &&
+ !(freeable < batch_size && total_scan >= freeable))
+ goto out;
+
+ do {
unsigned long ret;
+ unsigned long nr_to_scan = min(total_scan, batch_size);
- shrinkctl->nr_to_scan = batch_size;
+ shrinkctl->nr_to_scan = nr_to_scan;
ret = shrinker->scan_objects(shrinker, shrinkctl);
if (ret == SHRINK_STOP)
break;
freed += ret;
- count_vm_events(SLABS_SCANNED, batch_size);
- total_scan -= batch_size;
+ count_vm_events(SLABS_SCANNED, nr_to_scan);
+ total_scan -= nr_to_scan;
cond_resched();
- }
+ } while (total_scan >= batch_size);
+out:
/*
* move the unused scan count back into the shrinker in a
* manner that handles concurrent updates. If we exhausted the
--
1.7.10.4
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-01-17 19:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-17 19:25 [PATCH 1/3] mm: vmscan: shrink_slab: rename max_pass -> freeable Vladimir Davydov
2014-01-17 19:25 ` [PATCH 2/3] mm: vmscan: get rid of DEFAULT_SEEKS and document shrink_slab logic Vladimir Davydov
2014-02-04 21:58 ` Andrew Morton
2014-02-05 7:16 ` Vladimir Davydov
2014-02-05 20:52 ` Andrew Morton
2014-02-06 18:51 ` Vladimir Davydov
2014-01-17 19:25 ` Vladimir Davydov [this message]
2014-01-21 22:22 ` [PATCH 1/3] mm: vmscan: shrink_slab: rename max_pass -> freeable David Rientjes
2014-01-22 6:11 ` Vladimir Davydov
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=461628a5763b31bb36cc3dd7f6b89b06a907234f.1389982079.git.vdavydov@parallels.com \
--to=vdavydov@parallels.com \
--cc=akpm@linux-foundation.org \
--cc=dchinner@redhat.com \
--cc=devel@openvz.org \
--cc=glommer@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--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