Re: [PATCH] mm/damon/stat: avoid 32-bit overflow in idle percentiles

[SJ Park]

On Fri, 16 Oct 2026 17:22:58 +0800 Aveline Noir <jm5905938@xxxxxxxxx> wrote:

> Hi SJ,
> 
> On Thu, Oct 15, 2026 at 05:21:29PM -0700, SJ Park wrote:
> > This patch is sent as a followup of your previous bug report, right?
> > Unless it is very urgent, please make sure the previous discussion is
> > completed before making a followup action like sending this patch. As a
> > rule of thumb for DAMON, I'd suggest waiting for ~10 hours after the last
> > comment on the thread.
> 
> The patch was already prepared and additional tests were underway when
> your reply to the bug report arrived, so I went ahead and sent it.
> I'll leave more time for discussion before sending follow-up patches.
> 
> > What is 38?
> 
> 38 individual VM runs, forming 19 before/after pairs. The 20 same-image
> runs formed 10 control pairs.
> 
> > Do you have a plan to run more tests to be able to tell that?
> 
> I've run longer VM tests, but even same-kernel runs vary substantially,
> so the overall patch effect remains unclear. In a fixed-input 32-bit
> userspace test with 10 regions over 256 MiB, the median increase was
> 227 ns/call (+42%). The old code updated 15 entries, versus 101 with the
> fix. I haven't separated the extra updates from arithmetic cost.
> Maybe we could record region counts and sizes alongside VM timings to
> check whether both versions are doing comparable work.
> 
> > Any reason to use div64_ul() instead of div_u64()?
> 
> total_sz is unsigned long. div_u64() would truncate its divisor on 64-bit
> systems if it exceeds U32_MAX. div64_ul() preserves that width and maps
> to div_u64() on 32-bit.

All answers make sense.  Thank you.


Thanks,
SJ

[...]