From: SJ Park <sj@kernel.org>
To: Daemyung Kang <charsyam@gmail.com>
Cc: SJ Park <sj@kernel.org>,
damon@lists.linux.dev, linux-mm@kvack.org,
akpm@linux-foundation.org, bijantabatab@micron.com,
ravis.opensrc@micron.com
Subject: Re: [PATCH] mm/damon/vaddr: preserve migration weights above UINT_MAX
Date: Tue, 27 Oct 2026 06:53:54 -0700 [thread overview]
Message-ID: <20261027135354.149948-1-sj@kernel.org> (raw)
In-Reply-To: <20261027035431.1007584-1-charsyam@gmail.com>
Hello Daemyung,
On Tue, 27 Oct 2026 12:54:31 +0900 Daemyung Kang <charsyam@gmail.com> wrote:
> DAMOS migration accepts an unsigned int weight for each destination,
> but sums the weights into an unsigned int. If the total wraps to zero,
> no folio is migrated. Other wrapped totals select the wrong node.
Thank you for finding the issue.
But, is it realistic to have the weight_total overflow? Have you found the
issue on real usage? Or, theoretical?
>
> Sum weights into a u64 once per migration walk. Keep the existing
> 32-bit divisor path for totals up to UINT_MAX and use a 64-bit remainder
> for larger totals. Add KUnit coverage for the actual summing path and
> for destination selection at the overflow boundary.
Do we really need to support that user inputs? Unless we have a very real use
case that require such huge weight values, I'd prefer not.
How about just clearly notify users those are invalid parameters? We could do
so by adding weight_total overflow check to the central parameters validation
path: damos_commit_dests().
>
> Fixes: 19c1dc15c859 ("mm/damon/vaddr: use damos->migrate_dests in migrate_{hot,cold}")
Should we Cc: stable?
Thanks,
SJ
[...]
next prev parent reply other threads:[~2026-10-27 13:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-27 3:54 [PATCH] mm/damon/vaddr: preserve migration weights above UINT_MAX Daemyung Kang
2026-10-27 3:57 ` sashiko-bot
2026-10-27 6:45 ` Aveline Noir
2026-10-27 13:53 ` SJ Park [this message]
2026-10-27 23:57 ` CharSyam
2026-10-28 0:54 ` SJ Park
2026-10-28 14:44 ` CharSyam
2026-10-28 15:00 ` SJ Park
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=20261027135354.149948-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bijantabatab@micron.com \
--cc=charsyam@gmail.com \
--cc=damon@lists.linux.dev \
--cc=linux-mm@kvack.org \
--cc=ravis.opensrc@micron.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.