[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250419053824.1601470-1-gourry@gourry.net>
Date: Sat, 19 Apr 2025 01:38:22 -0400
From: Gregory Price <gourry@...rry.net>
To: linux-mm@...ck.org
Cc: cgroups@...r.kernel.org,
linux-kernel@...r.kernel.org,
kernel-team@...a.com,
longman@...hat.com,
hannes@...xchg.org,
mhocko@...nel.org,
roman.gushchin@...ux.dev,
shakeel.butt@...ux.dev,
muchun.song@...ux.dev,
tj@...nel.org,
mkoutny@...e.com,
akpm@...ux-foundation.org
Subject: [PATCH v3 0/2] vmscan: enforce mems_effective during demotion
Change reclaim to respect cpuset.mems_effective during demotion when
possible. Presently, reclaim explicitly ignores cpuset.mems_effective
when demoting, which may cause the cpuset settings to violated.
Implement cpuset_node_allowed() to check the cpuset.mems_effective
associated wih the mem_cgroup of the lruvec being scanned.
This requires renaming the existing cpuset_node_allowed() to be
cpuset_current_now_allowed() - which is more descriptive anyway - to
implement the new cpuset_node_allowed() which takes a target cgroup.
v3:
- remove cgroup indirection, call cpuset directly from memcontrol
- put mem_cgroup_node_allowed in memcontrol.c to reduce cpuset.h
include scope
- return true if mems_effective is empty, and don't walk the parents
as recommended by Waiman Long.
Gregory Price (2):
cpuset: rename cpuset_node_allowed to cpuset_current_node_allowed
vmscan,cgroup: apply mems_effective to reclaim
.../ABI/testing/sysfs-kernel-mm-numa | 14 ++++---
include/linux/cpuset.h | 9 +++-
include/linux/memcontrol.h | 6 +++
kernel/cgroup/cpuset.c | 25 ++++++++++-
mm/memcontrol.c | 6 +++
mm/page_alloc.c | 4 +-
mm/vmscan.c | 41 +++++++++++--------
7 files changed, 78 insertions(+), 27 deletions(-)
--
2.49.0
Powered by blists - more mailing lists