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
Date: Sun, 6 Feb 2022 14:28:18 -0800 (PST) [thread overview]
Message-ID: <bee4cb14-15d5-bef5-674-c0f574c35bc4@google.com> (raw)
In-Reply-To: <20220204110318.GA9391@swarm08>
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.
next prev parent reply other threads:[~2022-02-06 22:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-04 6:40 Jonghyeon Kim
2022-02-04 9:06 ` SeongJae Park
2022-02-04 11:03 ` Jonghyeon Kim
2022-02-06 22:28 ` David Rientjes [this message]
2022-02-07 1:56 ` Jonghyeon Kim
2022-02-04 12:03 ` kernel test robot
2022-02-04 12:23 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bee4cb14-15d5-bef5-674-c0f574c35bc4@google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sj@kernel.org \
--cc=tome01@ajou.ac.kr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox