Re: [RFC PATCH] mm/damon: reset thread status parameters upon kdamond termination

SeongJae Park
2026-04-01T00:29:24Z

On Tue, 31 Mar 2026 14:58:36 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:

> Hi SeongJae,
>
> On Mon, 30 Mar 2026 22:02:28 -0700 SeongJae Park <sj@kernel.org> wrote:
>
> > Nice catch!
> >
> > I guess this can easily reproducible? Sharing detailed reproduction steps
> > would be nice.
>
> I will include the reproduction steps in the next version.

Please completely answer questions. You didn't answer the first question.

>
> > > Solution
> > > ========
> > > Introduce a 'thread_status' structure to link the internal kdamond
> > > state with module parameters ('enabled' and 'kdamond_pid').
> > >
> > > Specifically:
> > > 1. Extend 'struct damon_ctx' to include pointers to the module's
> > > parameters.
> > > 2. Initialize these pointers in damon_lru_sort_apply_parameters()
> > > and damon_reclaim_apply_parameters() to point the respective
> > > module variables.
> > > 3. Implement damon_update_thread_status() to reset 'enabled' to
> > > false and 'kdamond_pid' to -1 when the kdamond thread finishes.
> >
> > This feels too much extension of core API for a problem that can more simply be
> > fixed. Can't we detect the unexpected termination of kdamond from the modules
> > and update the paramter values accordingly?
> >
> > If we cannot due to a limitation of the DAMON core API, I'd like to extend the
> > API for letting the caller detects the unexpected termination.
> >
> > Because this is an RFC and I already have question for the high level
> > direction, I will skip code level review.
> > I agree that the current approach was too heavy as it forced the DAMON
> > Core to directly manipulate module-specific parameters, leading to tight
> > coupling between layers.

Please do not add '> ' to your reply. This confuses me. Also, again, please
completely answer questions. You didn't answer if we can or cannot detect the
unexpected termination.

I will reply to below in another reply, as you added a few things to that part,
while cutting the above part. When you reply to your reply, please consider
keeping the previous reply part. Then I can reply to your two mails at one
place. That would help my life :)

Thanks,
SJ …