From: SJ Park <sj@kernel.org>
To: Liew Rui Yan <aethernet65535@gmail.com>
Cc: SJ Park <sj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
damon@lists.linux.dev, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] mm/damon: fix damos quota walk-position tracking
Date: Tue, 25 Aug 2026 06:54:57 -0700 [thread overview]
Message-ID: <20260825135458.64555-1-sj@kernel.org> (raw)
In-Reply-To: <20260825124616.5129-1-aethernet65535@gmail.com>
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.
>
> 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?
>
> Fix this by treating the fields as a rotating walk cursor:
>
> - Advance the cursor for every region walked while a quota is set,
> regardless of whether the region is applied or filtered out.
> - Remove the unconditional last-region reset.
> - Skip regions before the cursor, and rotate to the next valid target
> only after the current target has been fully walked.
> - Rename charge_{target,addr}_from to walk_{target,addr}_from and
> damos_skip_charged_region() to damos_skip_walked_region().
Because I don't understand the problem, I can't understand benefit of this
change. Again, more clarification would be helpful.
>
> Signed-off-by: Liew Rui Yan <aethernet65535@gmail.com>
> ---
> include/linux/damon.h | 6 +-
> mm/damon/core.c | 156 +++++++++++++++++++++++++++++-------------
> 2 files changed, 111 insertions(+), 51 deletions(-)
Quite amount of change. I will review the code after the high level
understanding is done.
Thanks,
SJ
[...]
next prev parent reply other threads:[~2026-08-25 13:55 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 [this message]
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
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=20260825135458.64555-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 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.