[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250424202207.50028-1-gourry@gourry.net>
Date: Thu, 24 Apr 2025 16:22:05 -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 v5 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 only
applies to cgroup/cpuset v2, as cpuset exists in a different hierarchy
than mem_cgroup in v1.
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.
v5:
- squash drop rcu_read_lock fixlet into second patch,
- changelog fixups
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 | 16 +++++---
include/linux/cpuset.h | 9 +++-
include/linux/memcontrol.h | 6 +++
kernel/cgroup/cpuset.c | 40 +++++++++++++++++-
mm/memcontrol.c | 6 +++
mm/page_alloc.c | 4 +-
mm/vmscan.c | 41 +++++++++++--------
7 files changed, 94 insertions(+), 28 deletions(-)
--
2.49.0
Powered by blists - more mailing lists