[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250422012616.1883287-1-gourry@gourry.net>
Date: Mon, 21 Apr 2025 21:26:13 -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 v4 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.
v4:
- explicitly expect v1 instead of checking for empty effective_mems.
this was the case anyway since cpuset and mem_cgroup are in different
heirarchy in v1.
- update docs to reflect this
- rcu_read_lock instead of taking a global lock.
- cpuset header fixup when compiled out.
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 | 30 +++++++++++++-
mm/memcontrol.c | 6 +++
mm/page_alloc.c | 4 +-
mm/vmscan.c | 41 +++++++++++--------
7 files changed, 84 insertions(+), 28 deletions(-)
--
2.49.0
Powered by blists - more mailing lists