Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Sun, 6 Feb 2022 14:28:18 -0800 (PST)
From:   David Rientjes <rientjes@google.com>
To:     Jonghyeon Kim <tome01@ajou.ac.kr>
cc:     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
In-Reply-To: <20220204110318.GA9391@swarm08>
Message-ID: <bee4cb14-15d5-bef5-674-c0f574c35bc4@google.com>
References: <20220204064059.6244-1-tome01@ajou.ac.kr> <20220204090642.2425-1-sj@kernel.org> <20220204110318.GA9391@swarm08>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

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?  

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.