Re: [RFC PATCH v2 1/4] mm/damon: Generic context creation for modules

[SeongJae Park <sj@kernel.org>]

On Wed, 11 Mar 2026 16:10:19 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:

> 
> 
> On 3/11/2026 3:57 AM, SeongJae Park wrote:
> > On Tue, 10 Mar 2026 16:24:17 +0000 <gutierrez.asier@huawei-partners.com> wrote:
> > 
> >> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> >>
> >> It is more elegant to have a generic version of new context creation
> >> which receives the mode as a parameter.
> >>
> >> Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> >> Co-developed-by: Anatoly Stepanov <stepanov.anatoly@huawei.com>
> >> ---
> >>  mm/damon/lru_sort.c       | 5 +++--
> >>  mm/damon/modules-common.c | 6 +++---
> >>  mm/damon/modules-common.h | 4 ++--
> >>  mm/damon/reclaim.c        | 5 +++--
> >>  4 files changed, 11 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/mm/damon/lru_sort.c b/mm/damon/lru_sort.c
> >> index 7bc5c0b2aea3..143ee0b21da6 100644
> >> --- a/mm/damon/lru_sort.c
> >> +++ b/mm/damon/lru_sort.c
> >> @@ -287,7 +287,8 @@ static int damon_lru_sort_apply_parameters(void)
> >>  	unsigned int hot_thres, cold_thres;
> >>  	int err;
> >>  
> >> -	err = damon_modules_new_paddr_ctx_target(&param_ctx, &param_target);
> >> +	err = damon_modules_new_ctx_target(&param_ctx, &param_target,
> >> +				DAMON_OPS_PADDR);
> > 
> > I like the name of the function is becoming shorter.  But I'm not happy with
> > the fact the resulting calling code becomes longer.
> > 
> > I understand you are doing this extension because you want a version of the
> > function for vaddr.  What about introducing another dedicated function, say,
> > damon_modules_new_vaddr_ctx_target() ?
> > 
> > And you can avoid duplicates between damon_modules_new_{p,v}addr_ctx_target()
> > by implementing internal function, say, damon_modules_new_ctx_target() that
> > receives the damon_ops_id.  And damon_modules_new_{P,v}addr_ctx_target() will
> > just wrappers of damon_modules_new_ctx_target().
> 
> Sure, I will do it.

Thanks for accepting my suggestion.

> 
> Since this is some generic code not related to the module I am working on,
> maybe I can move this to a different patch set that we can upstream. What do
> you think?

Please feel free to do so :)


Thanks,
SJ

[...]