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

From: SJ Park

Date: Thu Oct 15 2026 - 10:23:12 EST


Hi Avelin,

On Thu, 15 Oct 2026 04:24:12 -0700 Aveline Noir <jm5905938@xxxxxxxxx> 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

[...]