[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y1jpDfwBQId3GkJC@feng-clx>
Date: Wed, 26 Oct 2022 16:00:13 +0800
From: Feng Tang <feng.tang@...el.com>
To: Aneesh Kumar K V <aneesh.kumar@...ux.ibm.com>
CC: Andrew Morton <akpm@...ux-foundation.org>,
Johannes Weiner <hannes@...xchg.org>,
"Hocko, Michal" <mhocko@...e.com>, Tejun Heo <tj@...nel.org>,
Zefan Li <lizefan.x@...edance.com>,
Waiman Long <longman@...hat.com>,
"Huang, Ying" <ying.huang@...el.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"cgroups@...r.kernel.org" <cgroups@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Hansen, Dave" <dave.hansen@...el.com>,
"Chen, Tim C" <tim.c.chen@...el.com>,
"Yin, Fengwei" <fengwei.yin@...el.com>
Subject: Re: [PATCH] mm/vmscan: respect cpuset policy during page demotion
On Wed, Oct 26, 2022 at 03:49:48PM +0800, Aneesh Kumar K V wrote:
> On 10/26/22 1:13 PM, Feng Tang wrote:
> > In page reclaim path, memory could be demoted from faster memory tier
> > to slower memory tier. Currently, there is no check about cpuset's
> > memory policy, that even if the target demotion node is not allowd
> > by cpuset, the demotion will still happen, which breaks the cpuset
> > semantics.
> >
> > So add cpuset policy check in the demotion path and skip demotion
> > if the demotion targets are not allowed by cpuset.
> >
>
> What about the vma policy or the task memory policy? Shouldn't we respect
> those memory policy restrictions while demoting the page?
Good question! We have some basic patches to consider memory policy
in demotion path too, which are still under test, and will be posted
soon. And the basic idea is similar to this patch.
Thanks,
Feng
> -aneesh
Powered by blists - more mailing lists