Hi Hui,
teawater writes:
Memory.min, low, high can affect the global shrink behavior. They can help
task keep some pages to help protect performance.
But what I want is the low priority tasks (the tasks that performance is not
very important) do more shrink first. And when low priority tasks doesn’t
have enough pages to be dropped and system need more free page, shrink the
high priority task’s pages. Because at this time, system’s stable is more
important than the performance of priority task.
With memory.min and memory.low, I have no idea to config them to support this.
That is why I add global shrink priority.
For sure, that's what I'm suggesting you use memory.{min,low} for -- you define
some subset of the cgroup hierarchy as "protected", and then you bias reclaim
away from protected cgroups (and thus *towards* unprotected cgroups) by biasing
the size of LRU scanning. See my patch that went into 5.4 and the examples in
the commit message:
commit 9783aa9917f8ae24759e67bf882f1aba32fe4ea1
Author: Chris Down <chris@xxxxxxxxxxxxxx>
Date: Sun Oct 6 17:58:32 2019 -0700
mm, memcg: proportional memory.{low,min} reclaim
You can see how we're using memory.{low,min} to achieve this in this case
study[0]. It's not exactly equivalent technically to your solution, but the end
goals are similar.
Thanks,
Chris
0: https://facebookmicrosites.github.io/cgroup2/docs/overview.html#case-study-the-fbtax2-project
