Re: [PATCH 0/2] mm/damon: export symbols and introduce prdm module

[SeongJae Park <sj@kernel.org>]

On Mon, 22 Dec 2025 15:08:01 +0800 Enze Li <lienze@kylinos.cn> wrote:

> Hi SJ,
> 
> I appreciate you taking the time to provide such a detailed reply.  I
> have a few more questions.  Please see below.
> 
> On 12/19/25 7:46 PM, SeongJae Park wrote:
> > On Thu, 18 Dec 2025 21:46:37 +0800 Enze Li <lienze@kylinos.cn> wrote:
> > 
> >> On 2025/12/16 07:16, SeongJae Park wrote:
> >>> Hello Enze,
> >>>
> >>> On Mon, 15 Dec 2025 22:20:55 +0800 Enze Li <lienze@kylinos.cn> wrote:
> >>>
> >>>> This patchset makes DAMON's advanced memory management accessible to a
> >>>> broader range of users through two complementary enhancements.  First,
> >>>> it exports the necessary DAMON core symbols to enable building loadable
> >>>> kernel modules.  Building on this foundation, it then introduces the
> >>>> 'prdm' module, which extends the concept from the DAMON sample code
> >>>> (prcl.c) into a production-ready, user-friendly tool.
> >>>>
> >>>> The key strength of this module is its out-of-the-box simplicity: by
> >>>> simply specifying the PIDs of target processes and enabling the module,
> >>>> users can concurrently monitor memory access patterns across multiple
> >>>> processes and trigger proactive reclamation automatically.  This
> >>>> significantly lowers the barrier to using DAMON, allowing system
> >>>> administrators and regular users without deep kernel expertise to easily
> >>>> apply sophisticated memory optimization.
> >>>
> 
> <...>
> 
> >>
> >> Before developing prdm, I had considered implementing the same
> >> functionality based on DAMON_RECLAIM.  However, I gradually realized
> >> this would make DAMON_RECLAIM overly complex and less
> >> user-friendly—especially given its existing module-specific exported
> >> interfaces, which could confuse users.  This approach would create
> >> significant barriers to promoting wider DAMON adoption.  Consequently,
> >> building upon the prcl sample became the preferred choice.
> > 
> > I agree DAMON_RECLAIM already have no small number of parameters, and adding
> > more may make it look even more complex.  But, users may use only parameters
> > that really need to be set for their real use case.
> > 
> > For example, if we implement virtual address spaces mode in DAMON_RECLAIM, I
> > think we can simply add target_pid parameter that works very same to that of
> > prdm.  If it is unset, DAMON_RECLAIM works in the physical address mode.  If it
> > is set, it works in the virtual address mode.  Adding just one more parameter
> > that doesn't break old usage doesn't seem that complex change to me, at least
> > in terms of the user experience.
> 
> This should be viable, though it will take a moderate amount of extra
> time to develop.
> 
> > 
> > As I mentioned above, yet another example would be using
> > DAMOS_FILTER_TYPE_MEMCG.  For this, we may be able to add a parameter for
> > describing the memcg of critical processes.  Again, adding just one more
> > parameter that doesn't affect old usages doesn't seem too complex changes to
> > me, at least in terms of the user experience.
> > 
> > Meanwhile, I agree adding a new simpler module could make it easy for new
> > users.  But, I concern if having two modules for DAMON-based reclamation will
> > make users get difficulty at finding the correct one for their usage, since
> > they may now need to compare two modules.
> 
> Indeed, you're right.  From an architectural perspective, having two
> modules forces users to spend time distinguishing between them, which
> can cause confusion.
> 
> <...>
> 
> >>>
> >>> And, even more importantly, why it should be a loadable module rather than a
> >>> static module?  Do you have a specific use case that requires it to be a
> >>> loadable module?
> >>
> >> Yes, loadability is crucial for operational flexibility in practical
> >> production environments.  Beyond some obvious advantages, I would like
> >> to highlight a key scenario: system administrators can load the prdm
> >> module upon detecting memory pressure and unload it immediately after
> >> reclamation is complete, thereby eliminating any overhead during normal
> >> operation.
> > 
> > I agree always having prdm in kernel is an overhead.  But, I think the
> > overhead is not meaningfully big.  Also, as I mentioned above, my intended use
> > cases of DAMON modules is for cases that willing to simply always use the
> > modules.  If runtime controls are essential, I think using DAMON sysfs
> > interface or DAMON user-space tool is a better choice.
> 
> The prdm was developed based on samples/damon/prcl.c.  Would it be an
> acceptable modification to port the multi-process support feature to
> prcl?  Does that make sense to you?

Yes, that makes sense.

Please note that the purpose of sample modules is not to be used in the real
world products, but just explaining people how DAMON API can be used.  In this
case, I think multi-process support feature can let people better understand
how they can use DAMON for multiple processes, so I think that's good to add.

> 
> > 
> > Someone might argue DAMON sysfs interface is unnecessarily big compared to
> > prdm.  But, I have to ask again in the case.  Does the overhead really
> > meaningfully big for a real world use case?
> > 
> >> Furthermore, it supports zero-downtime updates, meaning that
> >> improvements targeting prdm can be deployed via a simple module reload,
> >> avoiding costly system reboots.
> > 
> > So I'm not really convinced at needs of prdm module at the moment.  But I agree
> > your above point is a good example advantage of loadable modules.  Also there
> > were private requests to support loadable DAMON modules.  No one among those
> > were for real production use case, and I understand you are also doing this
> > work for imaginable use cases, not your real products.  Please correct me if
> > I'm wrong.  But as the request is repeated, if you willing to convert existing
> > DAMON modules to support loadable modules build and expose required DAMON
> > functions for that, at least I wouldn't oppose.
> 
> Thank you for your feedback.  I would like to try it out.

Looking forward!

Please note that there could be objection from others, though.  In the case,
unless you have real world usage of loadable DAMON modules, I may have to agree
to the others' concerns, like I had to do so [1] last time.

[1] https://lore.kernel.org/damon/20231205172307.2310-1-sj@kernel.org/


Thanks,
SJ

[...]