[RFC/Discussion] mm/damon: Helping with alternative for watermarks

[Liew Rui Yan <aethernet65535@gmail.com>]

Hi SJ,

Regarding the alternative superior feature to replace watermarks [1], I
am very interested in helping you design and/or implement it.

To share my context: I am primarily using DAMON_RECLAIM on my personal
laptop.  During my usage, I found that using the free memory rate
(MemFree) as the default watermark metric is highly problematic for
modern Linux environments, because the kernel aggressively uses free
memory for page cache.  Therefore, I compiled a custom kernel that
supports monitoring the available memory rate (MemAvailable).  Since I
understand that the current watermark mechanism is not planned for
long-term extension, I refrained from proposing improvements to it, and
instead focused on understanding why that direction is limited.

I am very interested in understanding the design constraints behind
deprecating watermarks.  From my current perspective, watermarks have
these drawbacks as a run/stop mechanism:

- Mismatch between local monitoring and global triggers: When monitoring
  a specific target (e.g., via VADDR), the scheme's run/stop decision is
  currently tied to global system watermarks.  It is impossible to
  determine whether to run/stop the scheme based solely on that specific
  target's memory usage.  Therefore, the new mechanism might need to
  allow user-space to pause/resume schemes based on custom, target-aware
  metrics.

- Lack of diverse metrics: Watermarks currently lack support for metrics
  like PSI or inactive/active memory ratio, even though such metrics
  might be better suited for DAMOS auto-tuning goals.

However, I realize these features could probably be achieved by simply
improving the current watermarks.  Most of the drawbacks I can think of
are basically about "not enough metrics/customizability".

I assume there is a deeper architectural reason why you consider this
direction unsuitable for long-term evolution.  If you could share a bit
about those constraints, I would be able to think about the new
mechanism in the right direction, rather than approaching it from my own
assumptions.

My need for a more accurate trigger metric (like MemAvailable) and
always-on monitoring is exactly why I want to help build the new
mechanism.  I prefer to invest my time in the future architecture rather
than adding features to a mechanism that is about to be deprecated.

If you are open to this, I would be happy to start by reviewing the
design direction you have in mind, and then help with implementation or
testing where it is feasible for me to contribute meaningfully.

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

Best regards,
Rui Yan