From: Liew Rui Yan <aethernet65535@gmail.com>
To: sj@kernel.org
Cc: aethernet65535@gmail.com, akpm@linux-foundation.org,
damon@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [RFC PATCH] mm/damon: fix damos quota walk-position tracking
Date: Fri, 28 Aug 2026 09:54:29 +0800 [thread overview]
Message-ID: <20260828015429.131338-1-aethernet65535@gmail.com> (raw)
In-Reply-To: <20260828004049.62386-1-sj@kernel.org>
On Thu, 27 Aug 2026 17:40:48 -0700 SJ Park <sj@kernel.org> wrote:
> On Fri, 28 Aug 2026 02:08:22 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:
>
> > On Wed, 26 Aug 2026 17:44:38 -0700 SJ Park <sj@kernel.org> wrote:
> >
> > > On Wed, 26 Aug 2026 07:05:08 -0700 SJ Park <sj@kernel.org> wrote:
> > >
> > > > On Wed, 26 Aug 2026 18:24:13 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:
> > > >
> > > > > On Tue, 25 Aug 2026 06:54:57 -0700 SJ Park <sj@kernel.org> wrote:
> > > > >
> > > > > > On Tue, 25 Aug 2026 20:46:16 +0800 Liew Rui Yan <aethernet65535@gmail.com> 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?
> > >
> > > For example,
> > >
> > > '''
> > > --- a/mm/damon/core.c
> > > +++ b/mm/damon/core.c
> > > @@ -2686,14 +2686,15 @@ static bool damos_skip_charged_region(struct damon_target *t,
> > > if (quota->charge_target_from) {
> > > if (t != quota->charge_target_from)
> > > return true;
> > > - if (r == damon_last_region(t)) {
> > > - quota->charge_target_from = NULL;
> > > - quota->charge_addr_from = 0;
> > > - return true;
> > > - }
> > > if (quota->charge_addr_from &&
> > > - r->ar.end <= quota->charge_addr_from)
> > > + r->ar.end <= quota->charge_addr_from) {
> > > + if (r->ar.end == quota->charge_addr_from ||
> > > + r == damon_last_region(t)) {
> > > + quota->charge_target_from = NULL;
> > > + quota->charge_addr_from = 0;
> > > + }
> > > return true;
> > > + }
> > >
> > > if (quota->charge_addr_from && r->ar.start <
> > > quota->charge_addr_from) {
> > > '''
> > >
> >
> > Thank you for the example!
> >
> > While your approach works, I am curious, why should the cursor be reset
> > every time the function returns false (does not skip)?
>
> It doesn't. It resets charge_{target,addr}_from only once after the regions to
> skip are all skipped. Am I missing something?
You are right.
My concern was that the current
'return false == reset charge_{target, addr}_from' might be a bit hard
to understand. However, I realize that my change was quite significant.
To make the existing logic clearer for future readers, I think adding a
brief comment would be helpful. For example:
'''
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -2368,6 +2368,15 @@ static bool damos_skip_charged_region(struct damon_target *t,
damon_split_region_at(t, r, sz_to_skip);
return true;
}
+ /*
+ * Reset the charge_{target,addr}_from so that the remaining
+ * regions in this/next target can be processed normally. If
+ * the quota becomes full later during the walk,
+ * damos_apply_scheme() will update the
+ * charge_{target,addr}_from to the correct position.
+ * Otherwise, it implies that all applicable regions in this
+ * target have been processed.
+ */
quota->charge_target_from = NULL;
quota->charge_addr_from = 0;
}
'''
If this is not necessary or redundant, I am perfectly fine with dropping
it and just applying your minimal fix for the last-region issue in the
next revision.
Best regards,
Rui Yan
next prev parent reply other threads:[~2026-08-28 1:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 12:46 [RFC PATCH] mm/damon: fix damos quota walk-position tracking Liew Rui Yan
2026-08-25 12:58 ` sashiko-bot
2026-08-25 13:54 ` SJ Park
2026-08-26 10:24 ` Liew Rui Yan
2026-08-26 14:05 ` SJ Park
2026-08-27 0:44 ` SJ Park
2026-08-27 18:08 ` Liew Rui Yan
2026-08-28 0:40 ` SJ Park
2026-08-28 1:54 ` Liew Rui Yan [this message]
2026-08-28 2:31 ` SJ Park
-- strict thread matches above, loose matches on Subject: below --
2026-08-27 5:54 Liew Rui Yan
2026-08-27 6:02 ` Liew Rui Yan
2026-08-27 13:49 ` SJ Park
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260828015429.131338-1-aethernet65535@gmail.com \
--to=aethernet65535@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=damon@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.