From: Huan Yang <link@vivo.com>
To: Tejun Heo <tj@kernel.org>, Zefan Li <lizefan.x@bytedance.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Jonathan Corbet <corbet@lwn.net>,
Michal Hocko <mhocko@kernel.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Shakeel Butt <shakeelb@google.com>,
Muchun Song <muchun.song@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
Huang Ying <ying.huang@intel.com>,
Kefeng Wang <wangkefeng.wang@huawei.com>,
Peter Xu <peterx@redhat.com>,
"Vishal Moola (Oracle)" <vishal.moola@gmail.com>,
Yosry Ahmed <yosryahmed@google.com>,
Liu Shixin <liushixin2@huawei.com>,
Hugh Dickins <hughd@google.com>,
cgroups@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc: opensource.kernel@vivo.com, Huan Yang <link@vivo.com>
Subject: [RFC 0/4] Introduce unbalance proactive reclaim
Date: Wed, 8 Nov 2023 14:58:11 +0800 [thread overview]
Message-ID: <20231108065818.19932-1-link@vivo.com> (raw)
In some cases, we need to selectively reclaim file pages or anonymous
pages in an unbalanced manner.
For example, when an application is pushed to the background and frozen,
it may not be opened for a long time, and we can safely reclaim the
application's anonymous pages, but we do not want to touch the file pages.
This patchset extends the proactive reclaim interface to achieve
unbalanced reclamation. Users can control the reclamation tendency by
inputting swappiness under the original interface. Specifically, users
can input special values to extremely reclaim specific pages.
Example:
echo "1G" 200 > memory.reclaim (only reclaim anon)
echo "1G" 0 > memory.reclaim (only reclaim file)
echo "1G" 1 > memory.reclaim (only reclaim file)
Note that when performing unbalanced reclamation, the cgroup swappiness
will be temporarily adjusted dynamically to the input value. Therefore,
if the cgroup swappiness is further modified during runtime, there may
be some errors.
However, this is acceptable because the interface is dynamically called
by the user and the timing should be controlled by the user.
This patchset did not implement the type-based reclamation as expected
in the documentation.(anon or file) Because in addition to extreme unbalanced
reclamation, this patchset can also adapt to the reclamation tendency
allocated according to swappiness, which is more flexible.
Self test
========
After applying the following patches and myself debug patch, my self-test
results are as follows:
1. LRU test
===========
a. Anon unbalance reclaim
```
cat memory.stat | grep anon
inactive_anon 7634944
active_anon 7741440
echo "200M" 200 > memory.reclaim
cat memory.stat | grep anon
inactive_anon 0
active_anon 0
cat memory.reclaim_stat_summary(self debug interface)
[22368]sh total reclaimed 0 file, 3754 anon, covered item=0
```
b. File unbalance reclaim
```
cat memory.stat | grep file
inactive_file 82862080
active_file 48664576
echo "100M" 0 > memory.reclaim
cat memory.stat | grep file
inactive_file 34164736
active_file 18370560
cat memory.reclaim_stat_summary(self debug interface)
[22368]sh total reclaimed 13732 file, 0 anon, covered item=0
```
2. MGLRU test
============
a. Anon unbalance reclaim
```
echo y > /sys/kernel/mm/lru_gen/enabled
cat /sys/kernel/mm/lru_gen/enabled
0x0003
cat memory.stat | grep anon
inactive_anon 17653760
active_anon 1740800
echo "100M" 200 > memory.reclaim
cat memory.reclaim_stat_summary
[8251]sh total reclaimed 0 file, 5393 anon, covered item=0
```
b. File unbalance reclaim
```
cat memory.stat | grep file
inactive_file 17858560
active_file 5943296
echo "100M" 0 > memory.reclaim
cat memory.stat | grep file
inactive_file 491520
active_file 2764800
cat memory.reclaim_stat_summary
[8251]sh total reclaimed 5230 file, 0 anon, covered item=0
```
Patch 1-3 implement the functionality described above.
Patch 4 aims to implement proactive reclamation to the cgroupv1 interface
for use on Android.
Huan Yang (4):
mm: vmscan: LRU unbalance cgroup reclaim
mm: multi-gen LRU: MGLRU unbalance reclaim
mm: memcg: implement unbalance proactive reclaim
mm: memcg: apply proactive reclaim into cgroupv1
.../admin-guide/cgroup-v1/memory.rst | 38 +++++-
Documentation/admin-guide/cgroup-v2.rst | 16 ++-
include/linux/swap.h | 1 +
mm/memcontrol.c | 126 ++++++++++++------
mm/vmscan.c | 38 +++++-
5 files changed, 169 insertions(+), 50 deletions(-)
--
2.34.1
next reply other threads:[~2023-11-08 6:59 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-08 6:58 Huan Yang [this message]
2023-11-08 6:58 ` [PATCH 1/4] mm: vmscan: LRU unbalance cgroup reclaim Huan Yang
2023-11-08 6:58 ` [PATCH 2/4] mm: multi-gen LRU: MGLRU unbalance reclaim Huan Yang
2023-11-08 12:34 ` kernel test robot
2023-11-09 11:08 ` kernel test robot
2023-12-04 6:53 ` Dan Carpenter
2023-11-08 6:58 ` [PATCH 3/4] mm: memcg: implement unbalance proactive reclaim Huan Yang
2023-11-08 6:58 ` [PATCH 4/4] mm: memcg: apply proactive reclaim into cgroupv1 Huan Yang
2023-11-08 21:06 ` kernel test robot
2023-11-08 7:35 ` [RFC 0/4] Introduce unbalance proactive reclaim Huang, Ying
2023-11-08 7:53 ` Huan Yang
2023-11-08 8:09 ` Huang, Ying
2023-11-08 8:14 ` Yosry Ahmed
2023-11-08 8:21 ` Huan Yang
2023-11-08 9:00 ` Yosry Ahmed
2023-11-08 9:05 ` Huan Yang
2023-11-08 8:00 ` Yosry Ahmed
2023-11-08 8:26 ` Huan Yang
2023-11-08 8:59 ` Yosry Ahmed
2023-11-08 9:12 ` Huan Yang
2023-11-08 14:06 ` Michal Hocko
2023-11-09 1:56 ` Huan Yang
2023-11-09 3:15 ` Huang, Ying
2023-11-09 3:38 ` Huan Yang
2023-11-09 9:57 ` Michal Hocko
2023-11-09 10:29 ` Huan Yang
2023-11-09 10:39 ` Michal Hocko
2023-11-09 10:50 ` Huan Yang
2023-11-09 12:40 ` Michal Hocko
2023-11-09 13:07 ` Huan Yang
2023-11-09 13:46 ` Michal Hocko
2023-11-10 3:48 ` Huan Yang
2023-11-10 12:24 ` Michal Hocko
2023-11-13 2:17 ` Huan Yang
2023-11-13 6:10 ` Huang, Ying
2023-11-13 6:28 ` Huan Yang
2023-11-13 8:05 ` Huang, Ying
2023-11-13 8:26 ` Huan Yang
2023-11-14 9:54 ` Michal Hocko
2023-11-14 9:56 ` Michal Hocko
2023-11-15 6:52 ` Huang, Ying
2023-11-14 9:50 ` Michal Hocko
2023-11-10 1:19 ` Huang, Ying
2023-11-10 2:44 ` Huan Yang
2023-11-10 4:00 ` Huang, Ying
2023-11-10 6:21 ` Huan Yang
2023-11-10 12:32 ` Michal Hocko
2023-11-13 1:54 ` Huan Yang
2023-11-14 10:04 ` Michal Hocko
2023-11-14 12:37 ` Huan Yang
2023-11-14 13:03 ` Michal Hocko
2023-11-15 2:11 ` Huan Yang
2023-11-09 9:53 ` Michal Hocko
2023-11-09 10:55 ` Huan Yang
2023-11-09 12:45 ` Michal Hocko
2023-11-09 13:10 ` Huan Yang
2023-11-08 16:14 ` Andrew Morton
2023-11-09 1:58 ` Huan Yang
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=20231108065818.19932-1-link@vivo.com \
--to=link@vivo.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liushixin2@huawei.com \
--cc=lizefan.x@bytedance.com \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=opensource.kernel@vivo.com \
--cc=peterx@redhat.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeelb@google.com \
--cc=tj@kernel.org \
--cc=vishal.moola@gmail.com \
--cc=wangkefeng.wang@huawei.com \
--cc=willy@infradead.org \
--cc=ying.huang@intel.com \
--cc=yosryahmed@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