在 2023/11/8 16:59, Yosry Ahmed 写道:
On Wed, Nov 8, 2023 at 12:26 AM Huan Yang <link@xxxxxxxx> wrote:
在 2023/11/8 16:00, Yosry Ahmed 写道:
+Wei Xu +David Rientjes
On Tue, Nov 7, 2023 at 10:59 PM Huan Yang <link@xxxxxxxx> wrote:
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.
I proposed this a while back:
https://lore.kernel.org/linux-mm/CAJD7tkbDpyoODveCsnaqBBMZEkDvshXJmNdbk51yKSNgD7aGdg@xxxxxxxxxxxxxx/
Well to know this, proactive reclaim single type is usefull in our
production too.
The takeaway from the discussion was that swappiness is not the right
way to do this. We can add separate arguments to specify types of
memory to reclaim, as Roman suggested in that thread. I had some
patches lying around to do that at some point, I can dig them up if
that's helpful, but they are probably based on a very old kernel now,
and before MGLRU landed. IIRC it wasn't very difficult, I think I
added anon/file/shrinkers bits to struct scan_control and then plumbed
them through to memory.reclaim.
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)
The type of interface here is nested-keyed, so if we add arguments
they need to be in key=value format. Example:
echo 1G swappiness=200 > memory.reclaim
Yes, this is better.
As I mentioned above though, I don't think swappiness is the right way
of doing this. Also, without swappiness, I don't think there's a v1 vs
v2 dilemma here. memory.reclaim can work as-is in cgroup v1, it just
needs to be exposed there.
Cgroupv1 can't use memory.reclaim, so, how to exposed it? Reclaim this by
pass memcg's ID?
That was mainly about the idea that cgroup v2 does not have per-memcg
swappiness, so this proposal seems to be inclined towards v1, at least
I seem current comments of mem_cgroup_swappiness it is believed that
per-memcg swappiness can be added.
But, we first need to explain that using swappiness is a very useful way.
And in the discussions of your patchset, end that not use it.
conceptually. Either way, we need to add memory.reclaim to the v1
files to get it to work on v1. Whether this is acceptable or not is up
to the maintainers. I personally don't think it's a problem, it should
Yes, but, I understand that cgroup v2 is a trend, so it is
understandable that no
new interfaces are added to v1. :)
Maybe you can promoting the use of cgroupv2 on Android?
work as-is for v1.
