linux-kernel - Re: [PATCH] mm/damon: Rebase DAMON_RECALIM watermarks for NUMA nodes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20220207015616.GA7661@swarm08>
Date:   Mon, 7 Feb 2022 10:56:16 +0900
From:   Jonghyeon Kim <tome01@...u.ac.kr>
To:     David Rientjes <rientjes@...gle.com>
Cc:     Jonghyeon Kim <tome01@...u.ac.kr>, SeongJae Park <sj@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm/damon: Rebase DAMON_RECALIM watermarks for NUMA nodes

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.