Skip to contentSkip to conversation

mm/damon: conflict between DAMON_STAT and DAMON_LRU_SORT?

Question Liew Rui Yan 2 participants 5 messages Mar 13 – Mar 14

Subsystems (2)
Memory management DAMON
lore
Share & tools
lore

Liew Rui Yan

author
#0 lore raw

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

maintainer
#1 lore raw
Quoted 4 lines · On Fri, 13 Mar 2026 19:17:02 +0800 Liew Rui Yan <[email protected]>…

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.

Quoted 2 lines

If yes, should
this limitation be documented?

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

Quoted 16 lines

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

Quoted 7 lines

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.

Quoted 3 lines

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?

Quoted 7 lines

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/[email protected]

Thanks,
SJ

[...]

maintainer
#2 lore raw
In reply to Liew Rui Yan
Quoted 4 lines · On Fri, 13 Mar 2026 19:17:02 +0800 Liew Rui Yan <[email protected]>…

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.

Quoted 2 lines

If yes, should
this limitation be documented?

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

Quoted 8 lines

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

Quoted 7 lines

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.

Quoted 4 lines

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.

Quoted 4 lines

Questions
=========
1. Is this resource conflict between damon_stat and damon_lru_sort expected?

Yes, as I mentioned above.

Quoted 3 lines

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?

Quoted 7 lines

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/[email protected]
[2] https://github.com/damonitor/damon-tests/blob/master/corr/run.sh#L62

Thanks,
SJ

[...]

author
#3 lore raw
Quoted 6 lines · SeongJae Park

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

maintainer
#4 lore raw
Quoted 16 lines · On Sat, 14 Mar 2026 03:42:35 +0800 Liew Rui Yan <[email protected]>…
Quoted 6 lines · SeongJae Park

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.

Quoted 5 lines

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!

Quoted 4 lines

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 :)

Quoted 2 lines

Thanks again for your guidance and for maintaining DAMON!

My pleasure!

Thanks,
SJ

[...]