From: SeongJae Park <sj@kernel.org>
To: Bijan Tabatabai <bijan311@gmail.com>
Cc: SeongJae Park <sj@kernel.org>,
damon@lists.linux.dev, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
david@redhat.com, ziy@nvidia.com, matthew.brost@intel.com,
joshua.hahnjy@gmail.com, rakie.kim@sk.com, byungchul@sk.com,
gourry@gourry.net, ying.huang@linux.alibaba.com,
apopple@nvidia.com, bijantabatab@micron.com,
venkataravis@micron.com, emirakhur@micron.com,
ajayjoshi@micron.com, vtavarespetr@micron.com
Subject: Re: [RFC PATCH v2 2/2] mm/damon/paddr: Allow multiple migrate targets
Date: Sat, 21 Jun 2025 11:02:15 -0700 [thread overview]
Message-ID: <20250621180215.36243-1-sj@kernel.org> (raw)
In-Reply-To: <20250620180458.5041-3-bijan311@gmail.com>
Hi Bijan,
On Fri, 20 Jun 2025 13:04:58 -0500 Bijan Tabatabai <bijan311@gmail.com> wrote:
> From: Bijan Tabatabai <bijantabatab@micron.com>
>
> The migrate_{hot,cold} DAMONS actions take a parameter, target_nid, to
> indicate what node the actions should migrate pages to. In this patch,
> we allow passing in a list of migration targets into target_nid. When
> this is done, the mirgate_{hot, cold} actions will migrate pages between
> the specified nodes using the global interleave weights found at
> /sys/kernel/mm/mempolicy/weighted_interleave/node<N>. This functionality
> can be used to dynamically adjust how pages are interleaved in response
> to changes in bandwidth utilization to improve performance, as discussed
> in [1]. When only a single migration target is passed to target_nid, the
> migrate_{hot,cold} actions will act the same as before.
[...]
> include/linux/damon.h | 8 +--
> mm/damon/core.c | 9 ++--
> mm/damon/lru_sort.c | 2 +-
> mm/damon/paddr.c | 108 +++++++++++++++++++++++++++++++++++++--
> mm/damon/reclaim.c | 2 +-
> mm/damon/sysfs-schemes.c | 14 +++--
> samples/damon/mtier.c | 6 ++-
> samples/damon/prcl.c | 2 +-
> 8 files changed, 131 insertions(+), 20 deletions(-)
If we keep pursuing making DAMON users be able to specify multiple migration
destination nodes and their weights[1], I think we may need only paddr.c part
change of this patch in the final version of this great work.
[...]
> static unsigned long damon_pa_migrate(struct damon_region *r, struct damos *s,
> unsigned long *sz_filter_passed)
> {
> unsigned long addr, applied;
> - LIST_HEAD(folio_list);
> + struct rmap_walk_control rwc;
[...]
>
> addr = r->ar.start;
> while (addr < r->ar.end) {
> @@ -522,15 +599,38 @@ static unsigned long damon_pa_migrate(struct damon_region *r, struct damos *s,
> else
> *sz_filter_passed += folio_size(folio);
>
> + /*
> + * If there is only one target node, migrate there. Otherwise,
> + * interleave across the nodes according to the global
> + * interleave weights
> + */
> + if (nr_nodes == 1) {
> + target_nid = first_node(s->target_nids);
> + } else {
> + target_nid = NUMA_NO_NODE;
> + /* Updates target_nid */
> + rmap_walk(folio, &rwc);
> + }
So we are doing rmap_walk(), which is known to be not very fast, for getting
the target node id of this page, in a way very similar to that of weighted
interleaving, right? I don't think we really need to behave that same to
weighted interleaving with the cost.
I'd hence suggest to implement and use a simple weights handling mechanism
here. It could be roud-robin way, like weighted interleaving, or probabilistic
way, using damon_rand().
The round-robin way may be simpler in my opinion. For example,
unsigned int damos_pa_nid_to_migrate(struct damos_migrate_dest *dest)
{
static unsigned int nr_migrated = 0;
unsigned int total_weight = 0;
unsigned int weights_to_ignore;
size_t i;
for (i = 0; i < dest->nr_dests; i++)
total_weight += dest->weight_arr[i];
weights_to_ignore = nr_migrate++ % total_weight;
total_weight = 0;
for (i = 0; i < dest->nr_dests; i++) {
total_weight += dest->weight_arr[i];
if (total_weight >= weights_to_ignore)
return dest->node_id_arr[i];
}
WARN_ON_ONCE(1, "I don't know what I did wrong");
return 0;
}
Then, we could replace the above rmap_walk() call with this one. What do you
think?
Nothing stands out from other parts to me. I will do more thorough read on the
next revision, though.
[1] https://lore.kernel.org/20250621173639.35906-1-sj@kernel.org
Thanks,
SJ
[...]
next prev parent reply other threads:[~2025-06-21 18:02 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-20 18:04 [RFC PATCH v2 0/2] mm/damon/paddr: Allow interleaving in migrate_{hot,cold} actions Bijan Tabatabai
2025-06-20 18:04 ` [RFC PATCH v2 1/2] mm/mempolicy: Expose get_il_weight() to MM Bijan Tabatabai
2025-06-23 19:06 ` Gregory Price
2025-06-23 19:14 ` David Hildenbrand
2025-06-23 19:38 ` Gregory Price
2025-06-24 10:58 ` Huang, Ying
2025-06-20 18:04 ` [RFC PATCH v2 2/2] mm/damon/paddr: Allow multiple migrate targets Bijan Tabatabai
2025-06-21 18:02 ` SeongJae Park [this message]
2025-06-21 18:11 ` SeongJae Park
2025-06-23 14:08 ` Joshua Hahn
2025-06-23 16:50 ` SeongJae Park
2025-06-23 14:27 ` Bijan Tabatabai
2025-06-23 16:52 ` SeongJae Park
2025-06-23 14:16 ` Bijan Tabatabai
2025-06-23 17:52 ` SeongJae Park
2025-06-23 23:15 ` Bijan Tabatabai
2025-06-24 0:34 ` SeongJae Park
2025-06-24 16:01 ` Bijan Tabatabai
2025-06-24 22:33 ` SeongJae Park
2025-06-20 20:21 ` [RFC PATCH v2 0/2] mm/damon/paddr: Allow interleaving in migrate_{hot,cold} actions SeongJae Park
2025-06-20 21:47 ` Bijan Tabatabai
2025-06-20 23:13 ` SeongJae Park
2025-06-21 17:36 ` SeongJae Park
2025-06-23 14:39 ` Bijan Tabatabai
2025-06-23 16:32 ` SeongJae Park
2025-06-23 19:28 ` Gregory Price
2025-06-23 23:21 ` Bijan Tabatabai
2025-06-26 19:13 ` Gregory Price
2025-06-23 13:45 ` Joshua Hahn
2025-06-23 14:57 ` Bijan Tabatabai
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=20250621180215.36243-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=ajayjoshi@micron.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=bijan311@gmail.com \
--cc=bijantabatab@micron.com \
--cc=byungchul@sk.com \
--cc=damon@lists.linux.dev \
--cc=david@redhat.com \
--cc=emirakhur@micron.com \
--cc=gourry@gourry.net \
--cc=joshua.hahnjy@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.brost@intel.com \
--cc=rakie.kim@sk.com \
--cc=venkataravis@micron.com \
--cc=vtavarespetr@micron.com \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.