Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 7 Feb 2022 10:56:16 +0900
From:   Jonghyeon Kim <tome01@ajou.ac.kr>
To:     David Rientjes <rientjes@google.com>
Cc:     Jonghyeon Kim <tome01@ajou.ac.kr>, SeongJae Park <sj@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/damon: Rebase DAMON_RECALIM watermarks for NUMA nodes
Message-ID: <20220207015616.GA7661@swarm08>
References: <20220204064059.6244-1-tome01@ajou.ac.kr>
 <20220204090642.2425-1-sj@kernel.org>
 <20220204110318.GA9391@swarm08>
 <bee4cb14-15d5-bef5-674-c0f574c35bc4@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <bee4cb14-15d5-bef5-674-c0f574c35bc4@google.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On Sun, Feb 06, 2022 at 02:28:18PM -0800, David Rientjes wrote:
> On Fri, 4 Feb 2022, Jonghyeon Kim wrote:
> 
> > > > This patch allows kdamond thread to select watermark options for monitoring
> > > > specific node or whole system free memory.
> > > 
> > > Why only specific NUMA node or whole system, instead of each NUMA node?  Are
> > > you running DARC for only specific NUMA node?  If that's the case, I think
> > > implementing your own DAMON-based policy in user space might be a better
> > > choice.  For example, you could implement and use a user-space daemon that
> > > monitors free memory ratio of each NUMA node and adjusts the watermarks.
> > > 
> > 
> > I have tested DAMON_RECLAIM for each NUMA node by using a module. But, I felt
> > that the goal of DAMON_RECLAIM is dealing with the entire system memory or
> > specific monitoring regions by using module parameters. So, I hoped to add more
> > options for DAMON_RECLAIM on the NUMA system.
> > 
> > Another thing I considered is the problem of correlation between NUMA node range
> > and monitoring start/end addresses, such as "What if we monitor target that
> > spans multiple nodes?".
> > In that case, I guess we have to decide the policy for watermarks.
> > 
> > > Hope I'm not making you get me wrong.  You found the important limitation of
> > > DAMON_RECLAIM, thank you!  I really hope DAMON_RECLAIM to evolve to handle the
> > > case.  I'm just saying this patch looks like specialized for your special case,
> > > and there could be a better approach for that.
> > > 
> > 
> > If you agree that each NUMA node is able to have its own DAMON_RECLAIM daemon
> > threads, I will add that codes in the next patch.
> > 
> 
> It seems like one DAMON context per NUMA node is required for this, no?  
> 

Exactly, what I intend it.

> In other words, since each context has its own set of memory regions that 
> it monitors and set of watermarks that it must abide by, if we want per 
> NUMA node proactive reclaim then each node must have its own context that 
> is coordinated by userspace if we want to do system-wide proactive 
> reclaim.

Yes, that's why I was concerned about the correlation between the NUMA range and
monitoring regions by userspace parameter. Therefore, I plan to add new
parameters for per NUMA node proactive reclaim and specific monitoring target
regions including system-wide proactive reclaim.