From: Kirill Tkhai <ktkhai@virtuozzo.com>
To: akpm@linux-foundation.org, hannes@cmpxchg.org,
josef@toxicpanda.com, jack@suse.cz, hughd@google.com,
ktkhai@virtuozzo.com, darrick.wong@oracle.com, mhocko@suse.com,
aryabinin@virtuozzo.com, guro@fb.com,
mgorman@techsingularity.net, shakeelb@google.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: [PATCH RFC 0/3] mm: Reduce IO by improving algorithm of memcg pagecache pages eviction
Date: Wed, 09 Jan 2019 15:20:18 +0300 [thread overview]
Message-ID: <154703479840.32690.6504699919905946726.stgit@localhost.localdomain> (raw)
On nodes without memory overcommit, it's common a situation,
when memcg exceeds its limit and pages from pagecache are
shrinked on reclaim, while node has a lot of free memory.
Further access to the pages requires real device IO, while
IO causes time delays, worse powerusage, worse throughput
for other users of the device, etc.
Cleancache is not a good solution for this problem, since
it implies copying of page on every cleancache_put_page()
and cleancache_get_page(). Also, it requires introduction
of internal per-cleancache_ops data structures to manage
cached pages and their inodes relationships, which again
introduces overhead.
This patchset introduces another solution. It introduces
a new scheme for evicting memcg pages:
1)__remove_mapping() uncharges unmapped page memcg
and leaves page in pagecache on memcg reclaim;
2)putback_lru_page() places page into root_mem_cgroup
list, since its memcg is NULL. Page may be evicted
on global reclaim (and this will be easily, as
page is not mapped, so shrinker will shrink it
with 100% probability of success);
3)pagecache_get_page() charges page into memcg of
a task, which takes it first.
Below is small test, which shows profit of the patchset.
Create memcg with limit 20M (exact value does not matter much):
$ mkdir /sys/fs/cgroup/memory/ct
$ echo 20M > /sys/fs/cgroup/memory/ct/memory.limit_in_bytes
$ echo $$ > /sys/fs/cgroup/memory/ct/tasks
Then twice read 1GB file:
$ time cat file_1gb > /dev/null
Before (2 iterations):
1)0.01user 0.82system 0:11.16elapsed 7%CPU
2)0.01user 0.91system 0:11.16elapsed 8%CPU
After (2 iterations):
1)0.01user 0.57system 0:11.31elapsed 5%CPU
2)0.00user 0.28system 0:00.28elapsed 100%CPU
With the patch set applied, we have file pages are cached
during the second read, so the result is 39 times faster.
This may be useful for slow disks, NFS, nodes without
overcommit by memory, in case of two memcg access the same
files, etc.
---
Kirill Tkhai (3):
mm: Uncharge and keep page in pagecache on memcg reclaim
mm: Recharge page memcg on first get from pagecache
mm: Pass FGP_NOWAIT in generic_file_buffered_read and enable ext4
fs/ext4/inode.c | 1 +
include/linux/pagemap.h | 1 +
mm/filemap.c | 38 ++++++++++++++++++++++++++++++++++++--
mm/vmscan.c | 22 ++++++++++++++++++----
4 files changed, 56 insertions(+), 6 deletions(-)
--
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
next reply other threads:[~2019-01-09 12:20 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-09 12:20 Kirill Tkhai [this message]
2019-01-09 12:20 ` [PATCH 1/3] mm: Uncharge and keep page in pagecache on memcg reclaim Kirill Tkhai
2019-01-09 12:20 ` [PATCH 2/3] mm: Recharge page memcg on first get from pagecache Kirill Tkhai
2019-01-09 12:20 ` [PATCH 3/3] mm: Pass FGP_NOWAIT in generic_file_buffered_read and enable ext4 Kirill Tkhai
2019-01-09 14:11 ` [PATCH RFC 0/3] mm: Reduce IO by improving algorithm of memcg pagecache pages eviction Michal Hocko
2019-01-09 15:43 ` Kirill Tkhai
2019-01-09 17:10 ` Michal Hocko
2019-01-10 9:42 ` Kirill Tkhai
2019-01-10 9:57 ` Michal Hocko
2019-01-09 15:49 ` Josef Bacik
2019-01-09 16:08 ` Kirill Tkhai
2019-01-09 16:33 ` Josef Bacik
2019-01-10 10:06 ` Kirill Tkhai
2019-01-09 16:45 ` Johannes Weiner
2019-01-09 17:44 ` Shakeel Butt
2019-01-09 17:44 ` Shakeel Butt
2019-01-09 19:20 ` Johannes Weiner
2019-01-09 17:37 ` Shakeel Butt
2019-01-09 17:37 ` Shakeel Butt
2019-01-10 9:46 ` Kirill Tkhai
2019-01-10 19:19 ` Shakeel Butt
2019-01-10 19:19 ` Shakeel Butt
2019-01-11 12:17 ` Kirill Tkhai
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=154703479840.32690.6504699919905946726.stgit@localhost.localdomain \
--to=ktkhai@virtuozzo.com \
--cc=akpm@linux-foundation.org \
--cc=aryabinin@virtuozzo.com \
--cc=darrick.wong@oracle.com \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=josef@toxicpanda.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@suse.com \
--cc=shakeelb@google.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