Re: [BUG] DAMON_STAT: idle percentiles out of order on 32-bit

[SJ Park <sj@kernel.org>]

Hi Avelin,

On Thu, 15 Oct 2026 04:24:12 -0700 Aveline Noir <jm5905938@gmail.com> wrote:

> Hi,
> 
> In an i386 QEMU guest built from mm-new commit ad9f2d463666,
> DAMON_STAT reported these memory_idle_ms_percentiles values after a
> statistics update:
> 
>   guest uptime:       22.51 s
>   aggr_interval_us:   3200000
>   percentile 0:      19200 ms
>   percentile 50:         0 ms
>   percentile 100:        0 ms
> 
> The 0th percentile is greater than the 50th and 100th.  The guest had
> 256 MiB of RAM (MemTotal: 254216 kB), a running kdamond,
> CONFIG_X86_32=y, CONFIG_DAMON_STAT=y,
> CONFIG_DAMON_STAT_ENABLED_DEFAULT=y, and CONFIG_COMPAT_32BIT_TIME=y.
> aggr_interval_us changed from 0 to 1600000 and then 3200000, showing
> that statistics updates ran before the final read.
> 
> In damon_stat_set_idletime_percentiles(), the loop compares
> 
>   next_percentile <= accounted_bytes * 100 / total_sz
> 
> where accounted_bytes and total_sz are unsigned long.  On 32-bit, when
> total_sz exceeds 42,949,672 bytes, the wrapped product cannot yield
> 100%, even after all bytes are accounted for.  Upper entries in
> memory_idle_ms_percentiles then retain an earlier value or remain zero
> on first use.  DAMON_STAT monitors the system RAM address range, which
> exceeds that threshold in this guest.  I did not capture a per-region
> trace in this run.
> 
> The guest init read the module parameters after 22 seconds of uptime;
> it did not write to them.  The i386 config, guest init, serial log, and
> build/run steps:

Could you share more details about your real use case that require the setup
and how this becomes a real problem?


Thanks,
SJ

[...]