From: SJ Park <sj@kernel.org>
To: Liew Rui Yan <aethernet65535@gmail.com>
Cc: SJ Park <sj@kernel.org>, damon@lists.linux.dev, linux-mm@kvack.org
Subject: Re: [PATCH 2/2] mm/damon: skip deactivated schemes in watermark checks and add fallback sleep
Date: Fri, 7 Aug 2026 07:07:39 -0700 [thread overview]
Message-ID: <20260807140739.91238-1-sj@kernel.org> (raw)
In-Reply-To: <20260807093526.183009-3-aethernet65535@gmail.com>
Hello Liew,
On Fri, 7 Aug 2026 17:35:26 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:
> According to DAMOS design documentation, a scheme is deactivated when
> nr_snapshots reaches max_nr_snapshots. However, the previous
> kdamond_wait_activation() still checked the schemes which nr_snapshots
> reached max_nr_snapshots.
>
> This caused an issue - when all schemes were deactivated due to
> max_nr_snapshots, but their watermarks were still satisfied,
> damos_wmark_wait_us() would return 0, causing kdamond_wait_activation()
> to return 0 (activated). The main loop would then continue without
> sleeping, leading to unnecessary overhead since all schemes would be
> skipped in damon_do_apply_schemes().
This is an intended implementation.
When all schemes are deactivated by watermarks, DAMON stops monitoring. It was
implemented in the way because we didn't want DAMON consumes system resource in
the case. But, later it turned out DAMON's resource consumption is really
negligible. Rather, it is turned out that it makes DAMON runs with stale
history when it is activated again. Particularly, regions have 'age' and their
start/end addresses that was emerged before the deactivation. Those are
meaningless and could even cause wrong DAMOS decisions.
We don't want that anymore. For a case the user really want DAMON completely
stops, we introduced 'pause'. For max_nr_snapshot-based deactivation, we don't
intend to completely stop DAMON.
Maybe the documentation can be updated to further clarify this.
Thanks,
SJ
[...]
next prev parent reply other threads:[~2026-08-07 14:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 9:35 [RFC PATCH 0/2] mm/damon: fix nr_snapshots semantics and max_nr_snapshots check coverage Liew Rui Yan
2026-08-07 9:35 ` [PATCH 1/2] mm/damon: fix nr_snapshots counting using tried_applied flag Liew Rui Yan
2026-08-07 13:52 ` SJ Park
2026-08-07 9:35 ` [PATCH 2/2] mm/damon: skip deactivated schemes in watermark checks and add fallback sleep Liew Rui Yan
2026-08-07 14:07 ` SJ Park [this message]
2026-08-07 16:18 ` Liew Rui Yan
2026-08-08 0:07 ` SJ Park
2026-08-07 14:12 ` [RFC PATCH 0/2] mm/damon: fix nr_snapshots semantics and max_nr_snapshots check coverage SJ Park
2026-08-07 16:19 ` Liew Rui Yan
2026-08-07 23:59 ` 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=20260807140739.91238-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=aethernet65535@gmail.com \
--cc=damon@lists.linux.dev \
--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