Re: [PATCH 1/2] mm/damon/core: optimize kdamond_apply_schemes() by inverting scheme and region loops

[Josh Law <objecting@objecting.org>]

On 22 March 2026 21:44:18 GMT, SeongJae Park <sj@kernel.org> wrote:
>Hello Josh,
>
>On Sun, 22 Mar 2026 18:46:40 +0000 Josh Law <objecting@objecting.org> wrote:
>
>> Currently, kdamond_apply_schemes() iterates over all targets, then over all
>> regions, and finally calls damon_do_apply_schemes() which iterates over
>> all schemes. This nested structure causes scheme-level invariants (such as
>> time intervals, activation status, and quota limits) to be evaluated inside
>> the innermost loop for every single region.
>> 
>> If a scheme is inactive, has not reached its apply interval, or has already
>> fulfilled its quota (quota->charged_sz >= quota->esz), the kernel still
>> needlessly iterates through thousands of regions only to repeatedly
>> evaluate these same scheme-level conditions and continue.
>> 
>> This patch inlines damon_do_apply_schemes() into kdamond_apply_schemes()
>> and inverts the loop ordering. It now iterates over schemes on the outside,
>> and targets/regions on the inside.
>> 
>> This allows the code to evaluate scheme-level limits once per scheme.
>> If a scheme's quota is met or it is inactive, we completely bypass the
>> O(Targets * Regions) inner loop for that scheme. This drastically reduces
>> unnecessary branching, cache thrashing, and CPU overhead in the kdamond
>> hot path.
>
>That makes sense in high level.  But, this will make a kind of behavioral
>difference that could be user-visible.  I am failing at finding a clear use
>case that really depends on the old behavior.  But, still it feels like not a
>small change to me.
>
>So, I'd like to be conservative to this change, unless there are good evidences
>showing very clear and impactful real world benefits.  Can you share such
>evidences if you have?
>
>
>Thanks,
>SJ
>
>[...]


Hello, 


 Performance Scaling Scenarios (Speedup of New vs Old)                                                                       
 | Scenario Description      | Speedup |                                                                                     
 |---------------------------|---------|                                                                                     
 | Typical (5s, 1k regions)  |  1.9x |                                                                                       
 | Large Scale (5s, 10k reg) |  6.9x |                                                                                       
 | Multi-Scheme (20s, 1k reg) |  4.0x |                                                                                      
 | Idle Schemes (10s, 1k reg) |  6.9x |                                                                                      
 | No Quotas (All Active)    |  1.1x |


This here is a benchmark full of multiple real world scenarios (made in C) and the speedup


About real world usage, this improves performance massively with most consumer based systems.


V/R


Josh Law