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

[SeongJae Park <sj@kernel.org>]

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

[...]