Re: [RFC PATCH] mm/damon: fix damos quota walk-position tracking

[SJ Park]

On Wed, 26 Aug 2026 18:24:13 +0800 Liew Rui Yan <aethernet65535@xxxxxxxxx> wrote:

> On Tue, 25 Aug 2026 06:54:57 -0700 SJ Park <sj@xxxxxxxxxx> wrote:
> 
> > On Tue, 25 Aug 2026 20:46:16 +0800 Liew Rui Yan <aethernet65535@xxxxxxxxx> wrote:
> > 
> > > DAMOS uses charge_target_from/charge_addr_from to remember how far a
> > > quota-limited walk has progressed.  The current implementation has two
> > > problems:
> > > 
> > > 1. Once set, the cursor unconditionally skips and resets at the last
> > >    region of the tracked target, so the last region can be skipped even
> > >    when it has not been processed.
> > 
> > I don't fully understand this.  Could you please clarify more?  Maybe adding a
> > realistic example scenario would be helpful.
> > 
> 
> Problem: Unconditional skip of the last region
> 
> In the current damos_skip_charged_region(), there is this logic:
> 
>     if (r == damon_last_region(t)) {
>         quota->charge_target_from = NULL;
>         quota->charge_addr_from = 0;
>         return true; /* Skip */
>     }
> 
> Scenario:
> 1. Target has 2 regions: R1 (0-100 bytes) and R2 (100-200 bytes).
> 
> 2. Quota is configured to process only 50 bytes per window.
> 
> 3. Window 1: Processes R1 (0-50).  Quota is full.  Cursor is saved at
>    (Target, 50).
> 
> 4. Window 2: Skips R1 (0-50).  Processes R1 (50-100).  Quota is full.
>    Cursor is saved at (Target, 100), which is exactly the start of R2.
> 
> 5. Window 3: The loop reaches R2.  Because R2 is damon_last_region(t),
>    the old code unconditionally returns true, skipping R2 entirely and
>    resetting the cursor.
> 
> Result: R2 is permanently skipped even though it has never been
> processed.

Ok, makes sense.  The user impact should be not that big, though.

> 
> To fix this, the patch advances the cursor every time a region is
> walked, regardless of whether it is applied or filtered out.  This
> allows DAMON to accurately track whether the last region has already
> been visited, eliminating the need for the unconditional reset.

Sounds like a big change compared to the problem.  Why we cannot modify the
last region case?  Have you also considered other possible simpler approaches?

> 
> > > 
> > > 2. The cursor only advances when the quota becomes full.  Regions that
> > >    are filtered out do not move the cursor, and the scheme can remain
> > >    stuck on the same regions.
> > 
> > I don't fully understand this, either.  Could you pleae clarify more?
> > 
> 
> Problem 2 is a false positive.  As long as the quota is not full, DAMON
> will continue iterating to find applicable regions.  I mistakenly
> assumed in the commit message that encountering filtered-out or invalid
> regions would cause the cursor to stall.

Thank you for clarifying.  Please try to reduce this kind of false positives
from the next time.

> 
> This patch ensures that every target is traversed sequentially and
> deterministically, even when the quota is set very low.  I omitted this
> benefit in the initial problem description.  If you think it is okay, I
> will add it in the next revision.

What's the problem and benefit?  I still don't get it.  More clarification
would be nice.


Thanks,
SJ

[...]