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

[Enze Li <lienze@kylinos.cn>]

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?

> 
> 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.

Best Regards,
Enze

<...>