[Question] mm/damon: conflict between DAMON_STAT and DAMON_LRU_SORT?

[Question] mm/damon: conflict between DAMON_STAT and DAMON_LRU_SORT?

[Liew Rui Yan]

TL;DR
=====
When CONFIG_DAMON_STAT_ENABLED_DEFAULT=y, enabling damon_lru_sort via sysfs
"enabled" parameter returns -EBUSY. Is this expected behavior? If yes, should
this limitation be documented?

Reproduction
============
Environment:
- Kernel: 7.0.0-rc3+ (x86_64)
- VM: Virtme-ng (4G RAM, 2 CPUs)
- Config: CONFIG_DAMON_STAT_ENABLED_DEFAULT=y, CONFIG_DAMON_LRU_SORT=y

Steps:
1. cd /sys/module/damon_lru_sort/parameters
2. (optional) tune parameters: hot_thres_access_freq, cold_min_age, etc.
3. echo Y > enabled

Result:
  bash: echo: write error: Device or resource busy

Workaround:
  Disable CONFIG_DAMON_STAT_ENABLED_DEFAULT, or disable damon_stat at runtime
  before enabling damon_lru_sort.

Questions
=========
1. Is this resource conflict between damon_stat and damon_lru_sort expected?
2. If yes, should this limitation be documented in:
   - Documentation/admin-guide/mm/damon/lru_sort.rst
   - Documentation/admin-guide/mm/damon/stat.rst

Additional Context
==================
- On major distros (Arch/Fedora), CONFIG_DAMON_STAT_ENABLED_DEFAULT is typically
  unset (disabled), so this issue may not affect most users.
- However, for kernel developers or custom builds enabling both modules, clearer
  documentation or error handling would improve debuggability.

Best regards,
Liew Rui Yan

Re: [Question] mm/damon: conflict between DAMON_STAT and DAMON_LRU_SORT?

[SeongJae Park]

On Fri, 13 Mar 2026 19:17:02 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:

> TL;DR
> =====
> When CONFIG_DAMON_STAT_ENABLED_DEFAULT=y, enabling damon_lru_sort via sysfs
> "enabled" parameter returns -EBUSY. Is this expected behavior?

Yes, it is an expected behavior.  DAMON modules run in an exclusive manner like
this, to avoid interfering others' monitoring results.

I'm planning to make them be able to run together [1], but that's a future
work.  For now, this is the expected behavior.

> If yes, should
> this limitation be documented?

Good point!  Yes, it would be better to be documented.

> 
> Reproduction
> ============
> Environment:
> - Kernel: 7.0.0-rc3+ (x86_64)
> - VM: Virtme-ng (4G RAM, 2 CPUs)
> - Config: CONFIG_DAMON_STAT_ENABLED_DEFAULT=y, CONFIG_DAMON_LRU_SORT=y
> 
> Steps:
> 1. cd /sys/module/damon_lru_sort/parameters
> 2. (optional) tune parameters: hot_thres_access_freq, cold_min_age, etc.
> 3. echo Y > enabled
> 
> Result:
>   bash: echo: write error: Device or resource busy
> 
> Workaround:
>   Disable CONFIG_DAMON_STAT_ENABLED_DEFAULT, or disable damon_stat at runtime
>   before enabling damon_lru_sort.
> 
> Questions
> =========
> 1. Is this resource conflict between damon_stat and damon_lru_sort expected?

Yes, as I mentioned above.

> 2. If yes, should this limitation be documented in:
>    - Documentation/admin-guide/mm/damon/lru_sort.rst
>    - Documentation/admin-guide/mm/damon/stat.rst

Yes.  But, I think 'Special-Purpose Access-aware Kernel Modules' section of
Documentation/mm/damon/design.rst is a better place to document it.

Would you mind sending a patch for that?

> 
> Additional Context
> ==================
> - On major distros (Arch/Fedora), CONFIG_DAMON_STAT_ENABLED_DEFAULT is typically
>   unset (disabled), so this issue may not affect most users.
> - However, for kernel developers or custom builds enabling both modules, clearer
>   documentation or error handling would improve debuggability.

I agree.

[1] DAMON-X in https://lore.kernel.org/20260307210250.204245-1-sj@kernel.org


Thanks,
SJ

[...]

Re: [Question] mm/damon: conflict between DAMON_STAT and DAMON_LRU_SORT?

[SeongJae Park]

On Fri, 13 Mar 2026 19:17:02 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:

> TL;DR
> =====
> When CONFIG_DAMON_STAT_ENABLED_DEFAULT=y, enabling damon_lru_sort via sysfs
> "enabled" parameter returns -EBUSY. Is this expected behavior?

Yes, it is an expected behavior.  DAMON modules run in an exclusive manner like
this, to avoid interfering others' monitoring results.

I'm planning to make them be able to run together [1], but that's a future
work.  For now, this is the expected behavior.

> If yes, should
> this limitation be documented?

Good point!  Yes, it would be better to be documented.
 
> 
> Reproduction
> ============
> Environment:
> - Kernel: 7.0.0-rc3+ (x86_64)
> - VM: Virtme-ng (4G RAM, 2 CPUs)
> - Config: CONFIG_DAMON_STAT_ENABLED_DEFAULT=y, CONFIG_DAMON_LRU_SORT=y
> 
> Steps:
> 1. cd /sys/module/damon_lru_sort/parameters
> 2. (optional) tune parameters: hot_thres_access_freq, cold_min_age, etc.
> 3. echo Y > enabled
> 
> Result:
>   bash: echo: write error: Device or resource busy

Thank you for sharing this detailed steps.

> 
> Workaround:
>   Disable CONFIG_DAMON_STAT_ENABLED_DEFAULT, or disable damon_stat at runtime
>   before enabling damon_lru_sort.

Makes sense.  Indeed, DAMON tests use [2] this kind of workaround.
> 
> Questions
> =========
> 1. Is this resource conflict between damon_stat and damon_lru_sort expected?

Yes, as I mentioned above.

> 2. If yes, should this limitation be documented in:
>    - Documentation/admin-guide/mm/damon/lru_sort.rst
>    - Documentation/admin-guide/mm/damon/stat.rst

Yes.  But, I think 'Special-Purpose Access-aware Kernel Modules' section of
Documentation/mm/damon/design.rst is a better place to document it.

Would you mind sending a patch for that?

> 
> Additional Context
> ==================
> - On major distros (Arch/Fedora), CONFIG_DAMON_STAT_ENABLED_DEFAULT is typically
>   unset (disabled), so this issue may not affect most users.
> - However, for kernel developers or custom builds enabling both modules, clearer
>   documentation or error handling would improve debuggability.

I agree.

[1] DAMON-X in https://lore.kernel.org/20260307210250.204245-1-sj@kernel.org
[2] https://github.com/damonitor/damon-tests/blob/master/corr/run.sh#L62


Thanks,
SJ

[...]

Re: [Question] mm/damon: conflict between DAMON_STAT and DAMON_LRU_SORT?

[Liew Rui Yan]

On Fri, Mar 13, 2026 at 10:52 PM SeongJae Park <sj@kernel.org> wrote:
>
> Yes.  But, I think 'Special-Purpose Access-aware Kernel Modules' section of
> Documentation/mm/damon/design.rst is a better place to document it.
>
> Would you mind sending a patch for that?
>

Hi SeongJae,

Thank you so much for your quick and detailed reply!

I'm happy to send a documentation patch for this. As you suggested, I'll
add the explanation to the "Special-Purpose Access-aware Kernel Modules"
section of Documentation/mm/damon/design.rst.

Additionally, would it be helpful to add a short note with a :ref:
cross-reference in Documentation/admin-guide/mm/damon/lru_sort.rst
pointing to that section? I think this could help sysadmins quickly
understand the reason behind the -EBUSY error without having to dig deep
into the full design document.

I may need a few days to prepare the patch properly, I want to
familiarise myself with the reStructuredText syntax and the current
design.rst. I'll do my best to send it soon. Is that okay?

Thanks again for your guidance and for maintaining DAMON!

Best regards,
Liew Rui Yan

Re: [Question] mm/damon: conflict between DAMON_STAT and DAMON_LRU_SORT?

[SeongJae Park]

On Sat, 14 Mar 2026 03:42:35 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:

> On Fri, Mar 13, 2026 at 10:52 PM SeongJae Park <sj@kernel.org> wrote:
> >
> > Yes.  But, I think 'Special-Purpose Access-aware Kernel Modules' section of
> > Documentation/mm/damon/design.rst is a better place to document it.
> >
> > Would you mind sending a patch for that?
> >
> 
> Hi SeongJae,
> 
> Thank you so much for your quick and detailed reply!
> 
> I'm happy to send a documentation patch for this. As you suggested, I'll
> add the explanation to the "Special-Purpose Access-aware Kernel Modules"
> section of Documentation/mm/damon/design.rst.
> 
> Additionally, would it be helpful to add a short note with a :ref:
> cross-reference in Documentation/admin-guide/mm/damon/lru_sort.rst
> pointing to that section? I think this could help sysadmins quickly
> understand the reason behind the -EBUSY error without having to dig deep
> into the full design document.

Yes, I think that will be helpful.  Let's do so!

> 
> I may need a few days to prepare the patch properly, I want to
> familiarise myself with the reStructuredText syntax and the current
> design.rst. I'll do my best to send it soon. Is that okay?

That's perfectly fine.  No rush, take your time :)

> 
> Thanks again for your guidance and for maintaining DAMON!

My pleasure!


Thanks,
SJ

[...]