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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux