From: SJ Park <sj@kernel.org>
To: Liew Rui Yan <aethernet65535@gmail.com>
Cc: SJ Park <sj@kernel.org>,
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: Thu, 27 Aug 2026 17:40:48 -0700 [thread overview]
Message-ID: <20260828004049.62386-1-sj@kernel.org> (raw)
In-Reply-To: <20260827180822.4037-1-aethernet65535@gmail.com>
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?
>
> In my opinion, a cleaner and more deterministic approach is to reset the
> cursor only after the target has been fully iterated through.
So I will be able to give you some comments only after the above question is
answered.
Thanks,
SJ
[...]
next prev parent reply other threads:[~2026-08-28 0:41 UTC|newest]
Thread overview: 12+ 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 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 [this message]
2026-08-28 1:54 ` Liew Rui Yan
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=20260828004049.62386-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=aethernet65535@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=damon@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox