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

[SeongJae Park <sj@kernel.org>]

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.
> > 
> > I agree your points about the problems and the direction for improving the
> > situation.
> 
> Thank you, SJ!  Glad we are on the same page. :)
> 
> > However, we have a module for such use case, namely DAMON_RECLAIM.
> > It was designed for a reason that very same to what you described above.  One
> > key difference between DAMON_RECLAIM and prdm is, to my understanding,
> > DAMON_RECLAIM works for the physical address space, while prdm works for
> > virtual address spaces.
> 
> Yes, I have studied the implementation and architecture of this module
> quite thoroughly.  However, there are certain limitations when
> considering it for production use.

To my understanding, DAMON_RECLAIM is being used in multiple real world
products.  I understand you are saying there could be limitations for some
different production uses, and I agree.

> To my knowledge, few would perform
> indiscriminate page reclamation across the entire system.  In most
> practical scenarios, people prefer to protect critical processes from
> being swapped out, while applying page migration and reclamation only to
> less critical or performance-insensitive processes.

Thank you for kindly explaining above.  I agree such protection of critical
processes could be useful and required.  Nonetheless, to me, it sounds like you
could also do such protection using DAMOS_FILTER_TYPE_MEMCG.  Actually the
feature was developed for such use cases, and I recently met some people who
willing to use DAMON on their products in a way very similar to what you
described.  I suggested them to try DAMOS_FILTER_TYPE_MEMCG.  Have you
considered using DAMOS_FILTER_TYPE_MEMCG?

> 
> As we all know, frequent page migration inevitably introduces some
> latency to process response times.  Therefore, the ability to target
> large, inactive memory consumers for reclamation addresses a strong,
> genuine demand from real production environments.
> 
> > Is the virtual address spaces proactive reclamation is
> > what you really need?  If so, could you please further describe your expected
> > or planned usage of it?
> 
> Consider the following scenario: a host machine runs three virtual
> machines -- Machine A, Machine B, and Machine C.  It is known that
> Machine A handles massive traffic, while Machines B and C have
> relatively light workloads.  When memory pressure arises, besides
> releasing caches, the system can utilize prdm to perform precise page
> migration targeting Machines B and C, ensuring memory usage remains
> within a safe margin.
> 
> The data below, collected from a test environment, demonstrates the
> effectiveness of prdm.  After enabling prdm to monitor the two
> lower-activity VMs (2316, 2284), I observed that the DAMON-based prdm
> successfully migrated 5.5 GB of pages to the swap partition.
> 
>  PID USER  PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
> 2253 qemu  20   0 11.251g 3.822g  32.7m S 4.989 12.28   0:48.75
> qemu-system-x86
> 2316 qemu  20   0 12.191g 1.524g  34.3m S 5.322 4.893   0:49.05
> qemu-system-x86
> 2284 qemu  20   0 12.092g 1.184g  32.5m S 5.987 3.803   0:48.10
> qemu-system-x86
> 
> root@localhost /s/m/p/parameters# free -h
>        total        used        free      shared  buff/cache   available
> Mem:    31Gi        12Gi        15Gi       5.5Mi       3.2Gi        18Gi
> Swap:   31Gi       5.5Gi        25Gi

Thank you for sharing this nice explanation use case.  I think this all make
sense.

> 
> > 
> > If the virtual address spaces proactive reclamation is really what you need, I
> > think extending DAMON_RECLAIM for the purpose might be doable and even simpler
> > than introducing a new module.  How about doing so?
> 
> 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.

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.

For the above reasons, I still feel extending DAMON_RECLAIM is a better
approach in terms of user experience.

I'm not saying DAMON_RECLAIM's user interface is perfect.  Especially its
documentation may have many rooms to improve.

And I'm not very sure if the virtual address spaces reclamation is somewhat
need to be supported from modules rather than using DAMON sysfs interface or
DAMON user-space tool.  I implemented DAMON modules including DAMON_RECLAIM,
DAMON_LRU_SORT and DAMON_STAT for users who willing to enable those always, and
therefore want to avoid runtime controls.  That is, users can use those modules
by modifying the kernel command line options.  My expectation for DAMON modules
may not well documented.  If so, it's my bad.  I will try to recheck the
documentation and make that more clearly documented.

For virtual address spaces reclamation, however, runtime control is essential
since you don't know the pid of the processes before the runtime.  In the case,
I think using DAMON sysfs interface or DAMON user-space tool could be a better
approach.  Have you considered using those?

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

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.

> 
> Finally, I would like to add that designing prdm with an extremely
> simple workflow -- load the module, set the target PIDs, and enable the
> switch -- will contribute to the promotion of DAMON, allowing a broader
> user base to benefit from the DAMON system.

That workflow is definitely much easier than directly using DAMON sysfs
interface.  But, for the reason we have DAMON user-space tool.  Using it, the
workflow can also be as simple as prdm, like below.

   # damo start $TARGET_PID --damos_action pageout --damos_access_rate 0% 0% --damos_age 2m max


Thanks,
SJ

[...]