From: SJ Park <sj@kernel.org>
To: Aveline Noir <jm5905938@gmail.com>
Cc: SJ Park <sj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
damon@lists.linux.dev, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [BUG] DAMON: 32-bit overflow selects wrong sampling interval
Date: Thu, 15 Oct 2026 07:10:26 -0700 [thread overview]
Message-ID: <20261015141027.88149-1-sj@kernel.org> (raw)
In-Reply-To: <CANOyQmFkTQMEpR10sxjoB+8XMsk=m9DAJVnyxguwV2LLYCg09A@mail.gmail.com>
Hi Avelin,
On Thu, 15 Oct 2026 07:24:08 -0400 Aveline Noir <jm5905938@gmail.com> wrote:
> Hi,
>
> In an unmodified i386 QEMU kernel built from mm-new commit
> ad9f2d463666, an intervals goal selected a 2500 us sampling interval
> after the first aggregation. The same trace inputs give 2812 us with
> full-width arithmetic.
>
> The kernel has CONFIG_DAMON_VADDR, CONFIG_DAMON_SYSFS, and tracing
> enabled. The guest monitored a 1 MiB VADDR range as four contiguous
> 256 KiB regions, with sample_us=5000, aggr_us=100000, access_bp=400,
> aggrs=1, and min_sample_us=2500. The default minimum of 5000 us would
> hide the difference.
>
> At the first aggregation boundary, the four damos_before_apply records
> for kdamond.0 showed nr_accesses=1,1,1,3. The next
> damon_monitor_intervals_tune record showed sample_us=2500; sysfs then
> reported sample_us=2500 and aggr_us=50000. The records cover the same
> four 262144-byte regions before the first tune.
>
> For that aggregation, the inputs to damon_get_intervals_score() are:
>
> max_access_events = 4 * 262144 * 20 = 20971520
> access_events = (1 + 1 + 1 + 3) * 262144 = 1572864
>
> On 32-bit unsigned long, max_access_events * access_bp wraps before
> division by 10000. This gives a target of 409364, a score of 38422 bp,
> and the observed interval of 2500 us. With full-width arithmetic, the
> target is 838860, the score is 18750 bp, and the interval is 2812 us.
> The later mult_frac() remainder multiplication does not overflow in the
> observed 32-bit path, so the difference here comes from the target
> multiplication.
>
> The affected expression is in mm/damon/core.c. Widening only the
> target product would make the later 32-bit mult_frac() remainder
> multiplication overflow for these same inputs. The 2812 us result
> requires sufficient width throughout the score calculation.
>
> The 2500 us interval was measured on the unmodified kernel. I
> calculated 2812 us from the trace; I have not tested a patched kernel.
> The i386 config, guest init, serial/trace log, and build/run steps:
Could you share more details of your use case that this setup is needed and the
overflow becomes a problem?
Thanks,
SJ
[...]
next prev parent reply other threads:[~2026-10-15 14:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 11:24 [BUG] DAMON: 32-bit overflow selects wrong sampling interval Aveline Noir
2026-10-15 14:10 ` SJ Park [this message]
2026-10-15 15:36 ` Aveline Noir
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=20261015141027.88149-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=damon@lists.linux.dev \
--cc=jm5905938@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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.