| Message ID | 20241212095646.16164-1-hailong.liu@oppo.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC] mm/mglru: keep the root_memcg reclaim behavior the same as memcg reclaim | expand |
On Thu, Dec 12, 2024 at 1:57 AM hailong <hailong.liu@oppo.com> wrote: > > From: Hailong Liu <hailong.liu@oppo.com> > > commit a579086c99ed ("mm: multi-gen LRU: remove eviction fairness safeguard") said > Note that memcg LRU only applies to global reclaim. For memcg reclaim, > the eviction will continue, even if it is overshooting. This becomes > unconditional due to code simplification. > > Howeven, if we reclaim a root memcg by sysfs (memory.reclaim), the behavior acts > as a kswapd or direct reclaim. Hi Hailong, Why do you think this is a problem? > Fix this by remove the condition of mem_cgroup_is_root in > root_reclaim(). > Signed-off-by: Hailong Liu <hailong.liu@oppo.com> > --- > mm/vmscan.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 76378bc257e3..1f74f3ba0999 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -216,7 +216,7 @@ static bool cgroup_reclaim(struct scan_control *sc) > */ > static bool root_reclaim(struct scan_control *sc) > { > - return !sc->target_mem_cgroup || mem_cgroup_is_root(sc->target_mem_cgroup); > + return !sc->target_mem_cgroup; > } > > /** > -- > Actually we switch to mglru on kernel-6.1 and see different behavior on > root_mem_cgroup reclaim. so is there any background fot this? Reclaim behavior differs with MGLRU. https://lore.kernel.org/lkml/20221201223923.873696-1-yuzhao@google.com/ On even more recent kernels, regular LRU reclaim has also changed. https://lore.kernel.org/lkml/20240514202641.2821494-1-hannes@cmpxchg.org/ > Brs, > Hailong. >
On Thu, 12. Dec 10:22, T.J. Mercier wrote: > On Thu, Dec 12, 2024 at 1:57 AM hailong <hailong.liu@oppo.com> wrote: > > > > From: Hailong Liu <hailong.liu@oppo.com> > > > > commit a579086c99ed ("mm: multi-gen LRU: remove eviction fairness safeguard") said > > Note that memcg LRU only applies to global reclaim. For memcg reclaim, > > the eviction will continue, even if it is overshooting. This becomes > > unconditional due to code simplification. > > > > Howeven, if we reclaim a root memcg by sysfs (memory.reclaim), the behavior acts > > as a kswapd or direct reclaim. > > Hi Hailong, > > Why do you think this is a problem? > > > Fix this by remove the condition of mem_cgroup_is_root in > > root_reclaim(). > > Signed-off-by: Hailong Liu <hailong.liu@oppo.com> > > --- > > mm/vmscan.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index 76378bc257e3..1f74f3ba0999 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -216,7 +216,7 @@ static bool cgroup_reclaim(struct scan_control *sc) > > */ > > static bool root_reclaim(struct scan_control *sc) > > { > > - return !sc->target_mem_cgroup || mem_cgroup_is_root(sc->target_mem_cgroup); > > + return !sc->target_mem_cgroup; > > } > > > > /** > > -- > > Actually we switch to mglru on kernel-6.1 and see different behavior on > > root_mem_cgroup reclaim. so is there any background fot this? > > Reclaim behavior differs with MGLRU. > https://lore.kernel.org/lkml/20221201223923.873696-1-yuzhao@google.com/ > > On even more recent kernels, regular LRU reclaim has also changed. > https://lore.kernel.org/lkml/20240514202641.2821494-1-hannes@cmpxchg.org/ Thanks for the details. Take this as a example. root / | \ / | \ a b c | \ | \ d e IIUC, the mglru can resolve the direct reclaim latency due to the sharding. However, for the proactive reclaim, if we want to reclaim b, b->d->e, however, if reclaiming the root, the reclaim path is uncertain. The call stack is as follows: lru_gen_shrink_node()->shrink_many()->hlist_nulls_for_each_entry_rcu()->shrink_one() So, for the proactive reclaim of root_memcg, whether it is mglru or regular lru, calling shrink_node_memcgs() makes the behavior certain and reasonable for me. -- Help you, Help me, Hailong.
diff --git a/mm/vmscan.c b/mm/vmscan.c index 76378bc257e3..1f74f3ba0999 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -216,7 +216,7 @@ static bool cgroup_reclaim(struct scan_control *sc) */ static bool root_reclaim(struct scan_control *sc) { - return !sc->target_mem_cgroup || mem_cgroup_is_root(sc->target_mem_cgroup); + return !sc->target_mem_cgroup; } /**