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@xxxxxxxxxx> wrote:
> Hi Avelin,
>
> On Thu, 15 Oct 2026 07:24:08 -0400 Aveline Noir <jm5905938@xxxxxxxxx> 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
>
> [...]