Re: [PATCH 1/2] mm/damon: introduce damon_rand_fast() for per-ctx PRNG

[sashiko-bot@kernel.org]

Sashiko AI review found 1 potential issue(s):
- [High] damon_rand_fast() truncates the sampling range to 32 bits, preventing DAMON from monitoring the upper parts of memory regions larger than 4GB.
--

commit 094f8506b34920335d2088d576411d78378a8a58
Author: Jiayuan Chen <jiayuan.chen@shopee.com>

mm/damon: introduce damon_rand_fast() for per-ctx PRNG

This commit introduces a lockless, per-ctx PRNG function for the DAMON
sampling address hot path. It replaces the heavier get_random_u32_below()
call to reduce kdamond CPU usage on workloads with many regions.

> diff --git a/include/linux/damon.h b/include/linux/damon.h
> index f2cdb7c3f5e6c..0afdc08119c8c 100644
> --- a/include/linux/damon.h
> +++ b/include/linux/damon.h
[ ... ]
> @@ -843,8 +844,35 @@ struct damon_ctx {
[ ... ]
> +static inline unsigned long damon_rand_fast(struct damon_ctx *ctx,
> +					    unsigned long l, unsigned long r)
> +{
> +	u32 rnd = prandom_u32_state(&ctx->rnd_state);
> +	u32 span = (u32)(r - l);

Does this cast truncate the memory region span to 32 bits, preventing the
sampling of addresses beyond the first 4GB of a region?

If a region is larger than 4GB (which can occur with large anonymous
mappings or physical memory ranges), the explicit cast to u32 will wrap
around. For example, a 5GB region would result in a span of 1GB, and an
exactly 4GB region would result in a span of 0.

This would cause the PRNG to only sample addresses within that truncated
span, leaving the rest of the memory region unmonitored. While the previous
damon_rand() implementation had a similar limitation by passing an unsigned
long to get_random_u32_below(), could this be updated to correctly handle
64-bit region spans?

> +
> +	return l + (unsigned long)(((u64)rnd * span) >> 32);
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260423122340.138880-1-jiayuan.chen@linux.dev?part=1