Re: [RFC 0/4] Introduce unbalance proactive reclaim

From: Huan Yang
Date: Wed Nov 08 2023 - 02:53:34 EST


HI Huang, Ying

Thanks for reply.

在 2023/11/8 15:35, Huang, Ying 写道:
Huan Yang <link@xxxxxxxx> writes:

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.
From mem_cgroup_swappiness(), cgroupv2 doesn't have per-cgroup
swappiness. So you need to add that firstly?
Sorry for this mistake, we always work on cgroupv1, so, not notice
this commit 4550c4e, thank your for point that.

I see this commit comment that `that's a different discussion`, but,
to implements this, I will try add.


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.
If cgroup swappiness will be adjusted temporarily, why not just change
it via a script before/after proactive reclaiming?
IMO, this unbalance reclaim only takes effect for a single command,
so if it is pre-set using a script, the judgment of the reclamation tendency
may become complicated.

So, do you mean avoid use cgroup swappiness, just type anon or file to control
this extreme unbalanced reclamation?


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
We will not add new features to cgroupv1 in upstream.
Thx for point that. If this feature is worth further updating, the next patchset
will remove this patch.

.../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(-)
--
Best Regards,
Huang, Ying

Thanks,
Huan Yang