[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221123092132.2521764-1-yosryahmed@google.com>
Date: Wed, 23 Nov 2022 09:21:29 +0000
From: Yosry Ahmed <yosryahmed@...gle.com>
To: Shakeel Butt <shakeelb@...gle.com>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Johannes Weiner <hannes@...xchg.org>,
Michal Hocko <mhocko@...e.com>, Yu Zhao <yuzhao@...gle.com>,
Muchun Song <songmuchun@...edance.com>
Cc: "Matthew Wilcox (Oracle)" <willy@...radead.org>,
Vasily Averin <vasily.averin@...ux.dev>,
Vlastimil Babka <vbabka@...e.cz>,
Chris Down <chris@...isdown.name>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Yosry Ahmed <yosryahmed@...gle.com>
Subject: [PATCH v2 0/3] mm: memcg: fix protection of reclaim target memcg
This series fixes a bug in calculating the protection of the reclaim
target memcg where we end up using stale effective protection values from
the last reclaim operation, instead of completely ignoring the
protection of the reclaim target as intended. More detailed explanation
and examples in patch 1, which includes the fix.
Patches 2 & 3 introduce a selftest case that catches the bug.
v1 -> v2:
- Instead of adding a new helper, extended
mem_cgroup_supports_protection() to check if the current memcg is the
target memcg, renamed to mem_cgroup_unprotected() which is much easier
to reason about (suggested by Roman).
- Add a selftest case to catch the bug (suggested by Roman).
Yosry Ahmed (3):
mm: memcg: fix stale protection of reclaim target memcg
selftests: cgroup: refactor proactive reclaim code to reclaim_until()
selftests: cgroup: make sure reclaim target memcg is unprotected
include/linux/memcontrol.h | 31 ++++--
mm/vmscan.c | 11 ++-
.../selftests/cgroup/test_memcontrol.c | 96 ++++++++++++-------
3 files changed, 87 insertions(+), 51 deletions(-)
--
2.38.1.584.g0f3c55d4c2-goog
Powered by blists - more mailing lists