[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aAPbqbAzxsrGv0IR@slm.duckdns.org>
Date: Sat, 19 Apr 2025 07:21:45 -1000
From: Tejun Heo <tj@...nel.org>
To: Gregory Price <gourry@...rry.net>
Cc: linux-mm@...ck.org, 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, mkoutny@...e.com, akpm@...ux-foundation.org
Subject: Re: [PATCH v3 0/2] vmscan: enforce mems_effective during demotion
On Sat, Apr 19, 2025 at 01:38:22AM -0400, Gregory Price wrote:
> 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
>From cgroup POV:
Acked-by: Tejun Heo <tj@...nel.org>
Given that the operative changes are mostly in mm, it'd probably be best to
route through -mm, but please let me know if you wanna go through the cgroup
tree.
Thanks.
--
tejun
Powered by blists - more mailing lists