[BUG] DAMON: 32-bit overflow selects wrong sampling interval

[BUG] DAMON: 32-bit overflow selects wrong sampling interval

[Aveline Noir]

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:

  https://github.com/jm5905938/kernel-mail/tree/195d7017352a3d0f4a0475b98f3b03650f5c14ea/cases/2026/damon/2026-10-15-bug-reports/02-intervals-goal-32bit-overflow

Thanks,
Aveline Noir

Re: [BUG] DAMON: 32-bit overflow selects wrong sampling interval

[SJ Park]

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

[...]

Re: [BUG] DAMON: 32-bit overflow selects wrong sampling interval

[Aveline Noir]

Hi SJ,

I haven't seen this affect a real workload. I found it while testing
interval tuning on 32-bit.

I set min_sample_us=2500 to make the difference visible. The default
5000 us minimum hides it in this case. With the captured inputs, the
kernel picks 2500 us, while full-width arithmetic gives 2812 us.

The shorter interval could increase sampling overhead. I haven't
measured that overhead; the observed issue is the wrong tuning result.

Thanks,
Aveline Noir


On Thu, 15 Oct 2026 07:10:26 -0700, SJ Park <sj@kernel.org> wrote:
> 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
>
> [...]