Since proportional memory.{min, low} reclaim is introduced in
commit 9783aa9917f8 ("mm, memcg: proportional memory.{low,min} reclaim"),
it have been proved that the proportional reclaim is hard to understand and
the issues caused by it is harder to understand.[1]. That dilemma faced by
us is caused by that the proportional reclaim mixed up memcg and the
reclaim context.
In proportional reclaim, the whole reclaim context - includes the memcg
to be reclaimed and the reclaimer, should be considered, rather than
memcg only.
To make it clear, a new member 'protection' is introduced in the reclaim
context (struct shrink_control) to replace mem_cgroup_protection(). This
one is set when we check whether the memcg is protected or not.
After this change, the issue pointed by me[1] - a really old left-over
value can slow down target reclaim - can be fixed, and I think it could
also avoid some potential race.
Patch #1 and patch #2 is the preparation of patch #3.
[1]. https://lore.kernel.org/linux-mm/20200423061629.24185-1-laoar.shao@xxxxxxxxx
Yafang Shao (3):
mm: move struct scan_control into internal.h
mm: add reclaim context as a new parameter in mem_cgroup_protected()
mm: improvements on memcg protection functions
include/linux/memcontrol.h | 34 -----------
mm/internal.h | 101 +++++++++++++++++++++++++++++++
mm/memcontrol.c | 66 +++++++++++++++------
mm/vmscan.c | 118 ++-----------------------------------
4 files changed, 152 insertions(+), 167 deletions(-)
--
2.18.2
