[Question] mm/damon: min_nr_regions constraint and inconsistent error handling

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

Hi SeongJae,

TL;DR
=====
1. Why does DAMON require min_nr_regions >= 3? Is there a technical
   rationale?
2. Could we improve error reporting when sysfs parameter validation
   fails? Or document it?
3. [Bug?] DAMON_LRU_SORT doesn't disable itself when commit_inputs fails,
   contrary to documentation.

Details below. Happy to help with patches if helpful.

Details
=======

1. Error feedback for min_nr_regions validation
-----------------------------------------------

While configuring DAMON_LRU_SORT via sysfs, I noticed that setting
'min_nr_regions' to a value < 3 (e.g., 1) succeeds at write time, but
the error only appears later when writing 'Y' to the 'enabled' file,
which returns -EINVAL.

Since multiple parameters (intervals, watermarks, etc.) are often
configured together, a generic -EINVAL at enablement makes it difficult
to identify which specific parameter violated constraints.

Code reference: mm/damon/core.c:damon_set_attrs()

    if (attrs->min_nr_regions < 3)
        return -EINVAL;

Question:
1. What is the design rationale for requiring min_nr_regions >= 3? (eg.,
   algorithmic requirements, sampling accuracy, etc.)
2. Would it be acceptable to improve user feedback? For example:
   - Document this lower bound explicitly in
     Documentation/admin-guide/mm/damon/lru_sort.rst
   - Add pr_warn()/pr_debug() in damon_set_attrs() to log which
     parameter failed validation and why

I believe clearer errors or document would make DAMON tuning more
intuitive for sysadmins and developers.

---

2. Potential inconsistency in DAMON_LRU_SORT error handling
-----------------------------------------------------------

The documentation [1] states:
> "If invalid parameters are found while the re-reading, DAMON_LRU_SORT
 will be disabled."

However, testing on v7.0-rc4 shows that when commit_inputs fails (e.g.,
due to min_nr_regions < 3):
- The 'enabled' parameter remains 'Y'
- The kdamond thread continues running

This behavior may confuse users who expect the module to safely disable
itself upon configuration errors. Should commit_inputs failures trigger
an explicit disable (enabled=N)?

Reproduction steps:
-------------------
VM: virtme-ng 1.40 (x86_64)
Kernel: v7.0-rc4

    cd /sys/module/damon_lru_sort/parameters
    cat enabled 
    N

    # Initial setup - works fine
    echo 65535 > max_nr_regions 
    echo 3 > min_nr_regions 
    echo Y > enabled 
    cat kdamond_pid 
    91

    # Observed behavior:
    echo 1 > min_nr_regions 
    echo Y > commit_inputs 
    cat kdamond_pid 
    91
    cat enabled 
    Y

    # [kdamond.0] still alive
    ps aux | rg "kdamond"
    root        91  0.0  0.0      0     0 ?        I    22:03   0:00 [kdamond.0]

If this is confirmed as unintended behavior, I'd be glad to help
investigate and submit a fix.

---

Thanks for your time reviewing this!

Best regards,
Rui Yan

[1] https://docs.kernel.org/admin-guide/mm/damon/lru_sort.html

[...]