Re: [RFC PATCH v2.1 07/17] mm/damon/core: introduce damon_operations->prep_probes()

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Suboptimal short-circuit order in `kdamond_fn` causes unnecessary list traversals when `prep_probes` is not implemented.
--

--- Patch [7]: [RFC PATCH v2.1 07/17] mm/damon/core: introduce damon_operations->prep_probes() ---
commit 6cf31e4df3b58637535e88cd2f6425680fdfa9e6
Author: SJ Park <[email protected]>

mm/damon/core: introduce damon_operations->prep_probes()

This commit introduces a new prep_probes callback to the DAMON operations
set to execute damon_prep actions during monitoring preparation time. It
extends the core to check for and execute this callback if provided by the
underlying operation set.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 127d3a7c27280..19ab80f50bc4b 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c

[ ... ]

> @@ -3870,14 +3882,19 @@ static int kdamond_fn(void *data)
>  		unsigned long next_ops_update_sis = ctx->next_ops_update_sis;
>  		unsigned long sample_interval = ctx->attrs.sample_interval;
>  		bool access_check_disabled = damon_has_probe_weights(ctx);
> +		bool do_prep;
>  		unsigned int max_merge_score = 0, max_wsum;
>  		bool get_max_wsum;
>  
>  		if (kdamond_wait_activation(ctx))
>  			break;
>  
> +		do_prep = damon_has_prep(ctx) && ctx->ops.prep_probes;

[Severity: Low]
Could this short-circuit logic be reordered to check ctx->ops.prep_probes
before damon_has_prep(ctx)?

If the underlying operation set does not implement the prep_probes callback,
evaluating damon_has_prep() first will result in unnecessary list traversals
during every sample interval in the kdamond hot loop.

While the probe lists are typically short, evaluating ctx->ops.prep_probes
first would cleanly avoid this overhead when the callback is unused.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=7