The patch titled Subject: Revert "mm:vmscan: fix inaccurate reclaim during proactive reclaim" has been added to the -mm mm-hotfixes-unstable branch. Its filename is revert-mm-vmscan-fix-inaccurate-reclaim-during-proactive-reclaim.patch
This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches...
This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days
------------------------------------------------------ From: "T.J. Mercier" tjmercier@google.com Subject: Revert "mm:vmscan: fix inaccurate reclaim during proactive reclaim" Date: Sun, 21 Jan 2024 21:44:12 +0000
This reverts commit 0388536ac29104a478c79b3869541524caec28eb.
Proactive reclaim on the root cgroup is 10x slower after this patch when MGLRU is enabled, and completion times for proactive reclaim on much smaller non-root cgroups take ~30% longer (with or without MGLRU). With root reclaim before the patch, I observe average reclaim rates of ~70k pages/sec before try_to_free_mem_cgroup_pages starts to fail and the nr_retries counter starts to decrement, eventually ending the proactive reclaim attempt. After the patch the reclaim rate is consistently ~6.6k pages/sec due to the reduced nr_pages value causing scan aborts as soon as SWAP_CLUSTER_MAX pages are reclaimed. The proactive reclaim doesn't complete after several minutes because try_to_free_mem_cgroup_pages is still capable of reclaiming pages in tiny SWAP_CLUSTER_MAX page chunks and nr_retries is never decremented.
The docs for memory.reclaim say, "the kernel can over or under reclaim from the target cgroup" which this patch was trying to fix. Revert it until a less costly solution is found.
Link: https://lkml.kernel.org/r/20240121214413.833776-1-tjmercier@google.com Fixes: 0388536ac291 ("mm:vmscan: fix inaccurate reclaim during proactive reclaim") Signed-off-by: T.J. Mercier tjmercier@google.com Cc: Efly Young yangyifei03@kuaishou.com Cc: Johannes Weiner hannes@cmpxchg.org Cc: Michal Hocko mhocko@kernel.org Cc: Muchun Song muchun.song@linux.dev Cc: Roman Gushchin roman.gushchin@linux.dev Cc: Shakeel Butt shakeelb@google.com Cc: T.J. Mercier tjmercier@google.com Cc: Yu Zhao yuzhao@google.com Cc: stable@vger.kernel.org Signed-off-by: Andrew Morton akpm@linux-foundation.org ---
mm/memcontrol.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
--- a/mm/memcontrol.c~revert-mm-vmscan-fix-inaccurate-reclaim-during-proactive-reclaim +++ a/mm/memcontrol.c @@ -6977,8 +6977,8 @@ static ssize_t memory_reclaim(struct ker lru_add_drain_all();
reclaimed = try_to_free_mem_cgroup_pages(memcg, - min(nr_to_reclaim - nr_reclaimed, SWAP_CLUSTER_MAX), - GFP_KERNEL, reclaim_options); + nr_to_reclaim - nr_reclaimed, + GFP_KERNEL, reclaim_options);
if (!reclaimed && !nr_retries--) return -EAGAIN; _
Patches currently in -mm which might be from tjmercier@google.com are
revert-mm-vmscan-fix-inaccurate-reclaim-during-proactive-reclaim.patch