From: Liew Rui Yan <aethernet65535@gmail.com>
To: aethernet65535@gmail.com, sj@kernel.org
Cc: damon@lists.linux.dev, linux-mm@kvack.org
Subject: Re: [RFC PATCH] mm/damon: reset thread status parameters upon kdamond termination
Date: Wed, 1 Apr 2026 00:09:56 +0800 [thread overview]
Message-ID: <20260331160956.16312-1-aethernet65535@gmail.com> (raw)
In-Reply-To: <20260331065836.4364-1-aethernet65535@gmail.com>
Hi SeongJae,
On Tue, 31 Mar 2026 14:58:36 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:
> [...]
> Option 1: Introduce a generic termination callback
> ==================================================
> Add 'void *after_terminate_fn(void*)' and 'void *after_terminate_data'
> to 'struct damon_ctx' or 'struct damon_operations'. While this extends
> the Core API, it provides a clean notification mechanism. When kdamond
> exits for any reason, the module can perform its own cleanup (e.g.,
> resetting 'enabled' and 'kdamond_pid') within its own callback. This
> keeps the core logic decoupled from module parameters.
>
> Option 2: On-demand state correction in the module
> ==================================================
> In damon_{lru_sort, reclaim}_enabled_store(), if damon_stop() fails, we
> check is_kdamond_running(). If the kdamond is found to be terminated, we
> forcibly reset 'enabled' and 'kdamond_pid'.
>
> My perspective
> --------------
> I personally prefer OPTION-1 because it ensures the sysfs state in
> synchronized actively.
>
> OPTION-2 is simpler and avoids API changes, but it's a "passive" fix
> that only triggers when user atttempts a write operation. User might
> still see inconsistent value until they try to interact with the module.
> [...]
To avoid over-complicating the Core API (Option 1 or current approach),
I've implemented a lightweight, on-demand synchronization mechanism in
the module layer.
By overriding the '.get' operator of the 'enabled' parameter, we can
detect if kdamond has terminated and reset the module-level state right
before the user reads them.
Since sysfs parameter access is protected by 'kernel_param_lock', this
approach is race-free and keeps the DAMON core decoupling intact.
Core Implementation:
if (enabled && !damon_is_running(ctx)) {
enabled = false;
kdamond_pid = -1;
}
return param_get_bool(buffer, kp);
Test Log:
# cd /sys/module/damon_lru_sort/parameters/
# echo Y > enabled
# echo 3 > addr_unit
# echo Y > commit_inputs
# cat enabled
N
# cat kdamond_pid
-1
I think this approach is better than my previous OPTION-1 and OPTION-2.
Does this looks good to you?
Best regards,
Rui Yan
next prev parent reply other threads:[~2026-03-31 16:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-30 16:43 [RFC PATCH] mm/damon: reset thread status parameters upon kdamond termination Liew Rui Yan
2026-03-30 18:53 ` (sashiko review) " Liew Rui Yan
2026-03-30 19:51 ` Liew Rui Yan
2026-03-30 22:42 ` Liew Rui Yan
2026-03-31 5:02 ` SeongJae Park
2026-03-31 6:58 ` Liew Rui Yan
2026-03-31 16:09 ` Liew Rui Yan [this message]
2026-04-01 0:44 ` SeongJae Park
2026-04-01 8:24 ` Liew Rui Yan
2026-04-01 15:41 ` SeongJae Park
2026-04-02 5:34 ` Liew Rui Yan
2026-04-02 13:54 ` SeongJae Park
2026-04-03 4:34 ` Liew Rui Yan
2026-04-03 14:06 ` SeongJae Park
2026-04-01 0:29 ` SeongJae Park
2026-04-01 8:23 ` Liew Rui Yan
2026-04-02 0:40 ` SeongJae 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=20260331160956.16312-1-aethernet65535@gmail.com \
--to=aethernet65535@gmail.com \
--cc=damon@lists.linux.dev \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox