From: SeongJae Park <sj@kernel.org>
To: Liew Rui Yan <aethernet65535@gmail.com>
Cc: SeongJae Park <sj@kernel.org>, damon@lists.linux.dev, linux-mm@kvack.org
Subject: Re: [RFC PATCH] mm/damon: reset thread status parameters upon kdamond termination
Date: Fri, 3 Apr 2026 07:06:06 -0700 [thread overview]
Message-ID: <20260403140606.50524-1-sj@kernel.org> (raw)
In-Reply-To: <20260403043448.53045-1-aethernet65535@gmail.com>
On Fri, 3 Apr 2026 12:34:48 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:
> On Thu, 2 Apr 2026 06:54:39 -0700 SeongJae Park <sj@kernel.org> wrote:
>
> > On Thu, 2 Apr 2026 13:34:58 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:
[...]
> > > - When the user writes 'Y' to 'enabled', if enabled is already 'Y' but
> > > kdamond is terminated, we treat this as a restart request.
> >
> > This sounds bit odd to me. User shows enabled=Y and kdamond_pid!=-1. Why they
> > would write 'Y' again? Yes, they would notice kdamond is terminated in real,
> > using 'ps' like tool. But even in the case, I'd imagine users would write N to
> > enabled first, and then write Y to enabled. In other words, this could improve
> > the user experience, but seems not really necessary to me, at least as a
> > hotfix. What do you think?
>
> I see your point. I wasn't thinking of this as a hotfix at first, but
> you're right - for a bug like this, simple and backportable is the way
> to go.
>
> So I will drop the "Write Y to Restart" logic in the next version. I
> will only fix the state in the 'N' path and after commit failures.
Thank you for accepting my suggestion.
>
> >
> > >
> > > This way, even if kdamond terminates unexpectedly, the next user
> > > interaction will recover the state automatically.
> > >
> > > Does this approach sound reasonable?
> >
> > Yes, the plan for the next version sounds good to me.
>
> Great! Thank you for helping me scope this properly! :>
You're welcome :)
Thanks,
SJ
[...]
next prev parent reply other threads:[~2026-04-03 14:06 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
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 [this message]
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=20260403140606.50524-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 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.