| Message ID | 720e8e2c5b84efed5cf9980567794e7c799d179a.1744169302.git.hezhongkun.hzk@bytedance.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | add max arg to swappiness in memory.reclaim and lru_gen | expand |
On Wed, 9 Apr 2025 15:06:18 +0800 Zhongkun He <hezhongkun.hzk@bytedance.com> wrote: > With this patch 'commit <68cd9050d871> ("mm: add swappiness= arg to > memory.reclaim")', we can submit an additional swappiness=<val> argument > to memory.reclaim. It is very useful because we can dynamically adjust > the reclamation ratio based on the anonymous folios and file folios of > each cgroup. For example,when swappiness is set to 0, we only reclaim > from file folios. > > However,we have also encountered a new issue: when swappiness is set to > the MAX_SWAPPINESS, it may still only reclaim file folios. > > So, we hope to add a new arg 'swappiness=max' in memory.reclaim where > proactive memory reclaim only reclaims from anonymous folios when > swappiness is set to max. The swappiness semantics from a user > perspective remain unchanged. > > For example, something like this: > > echo "2M swappiness=max" > /sys/fs/cgroup/memory.reclaim > > will perform reclaim on the rootcg with a swappiness setting of 'max' (a > new mode) regardless of the file folios. Users have a more comprehensive > view of the application's memory distribution because there are many > metrics available. For example, if we find that a certain cgroup has a > large number of inactive anon folios, we can reclaim only those and skip > file folios, because with the zram/zswap, the IO tradeoff that > cache_trim_mode or other file first logic is making doesn't hold - > file refaults will cause IO, whereas anon decompression will not. > > With this patch, the swappiness argument of memory.reclaim has a new > mode 'max', means reclaiming just from anonymous folios both in traditional > LRU and MGLRU. > > ... > > --- a/Documentation/admin-guide/cgroup-v2.rst > +++ b/Documentation/admin-guide/cgroup-v2.rst > @@ -1348,6 +1348,9 @@ The following nested keys are defined. > same semantics as vm.swappiness applied to memcg reclaim with > all the existing limitations and potential future extensions. > > + The valid range for swappiness is [0-200, max], setting > + swappiness=max exclusively reclaims anonymous memory. Being able to assign either a number or a string feels a bit weird. Usually we use something like "-1" for a hack like this. eg, NUMA_NO_NODE. Perhaps we just shouldn't overload swappiness like this. Add a new tunable (swappiness_mode?) which can override the swappiness setting. I guess it doesn't matter much. We're used to adding messy interfaces ;)
On Thu, Apr 10, 2025 at 10:09 AM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Wed, 9 Apr 2025 15:06:18 +0800 Zhongkun He <hezhongkun.hzk@bytedance.com> wrote: > > > With this patch 'commit <68cd9050d871> ("mm: add swappiness= arg to > > memory.reclaim")', we can submit an additional swappiness=<val> argument > > to memory.reclaim. It is very useful because we can dynamically adjust > > the reclamation ratio based on the anonymous folios and file folios of > > each cgroup. For example,when swappiness is set to 0, we only reclaim > > from file folios. > > > > However,we have also encountered a new issue: when swappiness is set to > > the MAX_SWAPPINESS, it may still only reclaim file folios. > > > > So, we hope to add a new arg 'swappiness=max' in memory.reclaim where > > proactive memory reclaim only reclaims from anonymous folios when > > swappiness is set to max. The swappiness semantics from a user > > perspective remain unchanged. > > > > For example, something like this: > > > > echo "2M swappiness=max" > /sys/fs/cgroup/memory.reclaim > > > > will perform reclaim on the rootcg with a swappiness setting of 'max' (a > > new mode) regardless of the file folios. Users have a more comprehensive > > view of the application's memory distribution because there are many > > metrics available. For example, if we find that a certain cgroup has a > > large number of inactive anon folios, we can reclaim only those and skip > > file folios, because with the zram/zswap, the IO tradeoff that > > cache_trim_mode or other file first logic is making doesn't hold - > > file refaults will cause IO, whereas anon decompression will not. > > > > With this patch, the swappiness argument of memory.reclaim has a new > > mode 'max', means reclaiming just from anonymous folios both in traditional > > LRU and MGLRU. > > > > ... > > > > --- a/Documentation/admin-guide/cgroup-v2.rst > > +++ b/Documentation/admin-guide/cgroup-v2.rst > > @@ -1348,6 +1348,9 @@ The following nested keys are defined. > > same semantics as vm.swappiness applied to memcg reclaim with > > all the existing limitations and potential future extensions. > > > > + The valid range for swappiness is [0-200, max], setting > > + swappiness=max exclusively reclaims anonymous memory. > > Being able to assign either a number or a string feels a bit weird. > Usually we use something like "-1" for a hack like this. eg, > NUMA_NO_NODE. > > Perhaps we just shouldn't overload swappiness like this. Add a new > tunable (swappiness_mode?) which can override the swappiness setting. > > I guess it doesn't matter much. We're used to adding messy interfaces ;) > Hi Andrew, thanks for your review. In the initial patch, I used 200 (the maximum value of swappiness) to represent the semantics of reclaiming only from anonymous pages. However, someone pointed out that the current usage needs some fine-tuning. Later discussions suggested using max(swappiness=201) to represent this specific semantic explicitly in the code. It was then discovered that MGLRU already includes this logic(201), so it's only necessary to make the intention of the code clearer. So we can add the max to memory.reclaim and lru_gen. More info please see: https://lore.kernel.org/all/Z9Rs8ZtgkupXpFYn@google.com/ >
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 1a16ce68a4d7..472c01e0eb2c 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1348,6 +1348,9 @@ The following nested keys are defined. same semantics as vm.swappiness applied to memcg reclaim with all the existing limitations and potential future extensions. + The valid range for swappiness is [0-200, max], setting + swappiness=max exclusively reclaims anonymous memory. + memory.peak A read-write single value file which exists on non-root cgroups. diff --git a/include/linux/swap.h b/include/linux/swap.h index db46b25a65ae..f57c7e0012ba 100644 --- a/include/linux/swap.h +++ b/include/linux/swap.h @@ -414,6 +414,10 @@ extern unsigned long try_to_free_pages(struct zonelist *zonelist, int order, #define MEMCG_RECLAIM_PROACTIVE (1 << 2) #define MIN_SWAPPINESS 0 #define MAX_SWAPPINESS 200 + +/* Just recliam from anon folios in proactive memory reclaim */ +#define SWAPPINESS_ANON_ONLY (MAX_SWAPPINESS + 1) + extern unsigned long try_to_free_mem_cgroup_pages(struct mem_cgroup *memcg, unsigned long nr_pages, gfp_t gfp_mask, diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 421740f1bcdc..b0b3411dc0df 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -4396,11 +4396,13 @@ static ssize_t memory_oom_group_write(struct kernfs_open_file *of, enum { MEMORY_RECLAIM_SWAPPINESS = 0, + MEMORY_RECLAIM_SWAPPINESS_MAX, MEMORY_RECLAIM_NULL, }; static const match_table_t tokens = { { MEMORY_RECLAIM_SWAPPINESS, "swappiness=%d"}, + { MEMORY_RECLAIM_SWAPPINESS_MAX, "swappiness=max"}, { MEMORY_RECLAIM_NULL, NULL }, }; @@ -4434,6 +4436,9 @@ static ssize_t memory_reclaim(struct kernfs_open_file *of, char *buf, if (swappiness < MIN_SWAPPINESS || swappiness > MAX_SWAPPINESS) return -EINVAL; break; + case MEMORY_RECLAIM_SWAPPINESS_MAX: + swappiness = SWAPPINESS_ANON_ONLY; + break; default: return -EINVAL; } diff --git a/mm/vmscan.c b/mm/vmscan.c index b620d74b0f66..c99a6a48d0bc 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -2503,6 +2503,13 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, goto out; } + /* Proactive reclaim initiated by userspace for anonymous memory only */ + if (swappiness == SWAPPINESS_ANON_ONLY) { + WARN_ON_ONCE(!sc->proactive); + scan_balance = SCAN_ANON; + goto out; + } + /* * Do not apply any pressure balancing cleverness when the * system is close to OOM, scan both anon and file equally
With this patch 'commit <68cd9050d871> ("mm: add swappiness= arg to memory.reclaim")', we can submit an additional swappiness=<val> argument to memory.reclaim. It is very useful because we can dynamically adjust the reclamation ratio based on the anonymous folios and file folios of each cgroup. For example,when swappiness is set to 0, we only reclaim from file folios. However,we have also encountered a new issue: when swappiness is set to the MAX_SWAPPINESS, it may still only reclaim file folios. So, we hope to add a new arg 'swappiness=max' in memory.reclaim where proactive memory reclaim only reclaims from anonymous folios when swappiness is set to max. The swappiness semantics from a user perspective remain unchanged. For example, something like this: echo "2M swappiness=max" > /sys/fs/cgroup/memory.reclaim will perform reclaim on the rootcg with a swappiness setting of 'max' (a new mode) regardless of the file folios. Users have a more comprehensive view of the application's memory distribution because there are many metrics available. For example, if we find that a certain cgroup has a large number of inactive anon folios, we can reclaim only those and skip file folios, because with the zram/zswap, the IO tradeoff that cache_trim_mode or other file first logic is making doesn't hold - file refaults will cause IO, whereas anon decompression will not. With this patch, the swappiness argument of memory.reclaim has a new mode 'max', means reclaiming just from anonymous folios both in traditional LRU and MGLRU. Here is the previous discussion: https://lore.kernel.org/all/20250314033350.1156370-1-hezhongkun.hzk@bytedance.com/ https://lore.kernel.org/all/20250312094337.2296278-1-hezhongkun.hzk@bytedance.com/ https://lore.kernel.org/all/20250318135330.3358345-1-hezhongkun.hzk@bytedance.com/ Suggested-by: Yosry Ahmed <yosry.ahmed@linux.dev> Signed-off-by: Zhongkun He <hezhongkun.hzk@bytedance.com> --- Documentation/admin-guide/cgroup-v2.rst | 3 +++ include/linux/swap.h | 4 ++++ mm/memcontrol.c | 5 +++++ mm/vmscan.c | 7 +++++++ 4 files changed, 19 insertions(+)