Damon

2025-12-08 update: The RFC v3 is posted. From the very early days of DAMON, there were attempts to extend it for cpus-aware monitoring and write-only monitoring. In 2022, Xin Hao proposed extending DAMON for NUMA access statistics. In 2022 and 2025, Pedro Demarchi Gomes proposed extending DAMON for writes-only monitoring. Those proposals are not yet upstreamed though. We continued similar DAMON extension discussions publicly and privately, with multiple parties, though....

The initial version of this post was initially posted to DAMON mailing list as https://lore.kernel.org/20241108232536.73843-1-sj@kernel.org Posting it here too, for visibility and after-posting updates for any needs. One of common issues that I received from DAMON users is that DAMON’s monitoring results show hot regions much less than expected. Specifically, the users find regions of only zero or low ’nr_accesses’ value from the DAMON-generated access pattern snapshots. In some cases, it turned out the problem can be alleviated by tuning DAMON parameters or changing the way to interpret the results....

I just made a DAMON logo using DAMON, like below. $ git clone https://github.com/sjp38/masim && cd masim $ cat damon_pixel_2 11111111 11 11 111111 11111111 11 11 11111111 11111111 1111 11111111 11111111 11 11 11111111 11111111 1111 11111111 $ ./pixels_to_access_config.py ./damon_pixel_2 $((100*1024*1024)) 300 damon.cfg $ sudo damo record "./masim ./configs/stairs.cfg" $ sudo damo report heatmap --output damon.png The output is below: The cropped one:

Below is a list of news around DAMON project. This list is not exhaustive but just a DAMON maintainer’s collection of news. If you find a news that should be added to this list, please let us know at sj@kernel.org and/or damon@lists.linux.dev. 2026 2026-02-17: LSF/MM/BPF topic for extending DAMON for per-CPUs/threads/reads/writes monitoring is proposed. 2026-02-16: DAMON yearly retrospect for 2024 has posted. 2026-02-10: An LSF/MM/BPF topic proposal for DAMON-based access-aware Transparent Hugepages is posted....

This document helps you estimating the amount of benefit that you could get from DAMON-based system optimizations, and describes how you could achieve it. Check The Signs No optimization can provide same extent of benefit to every case. Therefore you should first guess how much improvements you could get using DAMON. If some of below conditions match your situation, you could consider using DAMON. Low IPC and High Cache Miss Ratios....

DAMON is lightweight. It increases system memory usage by 0.39% and slows target workloads down by 1.16%. DAMON is accurate and useful for memory management optimizations. An experimental DAMON-based operation scheme for THP, namely ’ethp’, removes 76.15% of THP memory overheads while preserving 51.25% of THP speedup. Another experimental DAMON-based ‘proactive reclamation’ implementation, namely ‘prcl’, reduces 93.38% of residential sets and 23.63% of system memory footprint while incurring only 1.22% runtime overhead in the best case (parsec3/freqmine)....

DAMON contains a number of tests based on the kselftest and kunit in its patchset itself. As it is preferred to contain only tests having short runtime in kernel tree, I organized time consuming tests in a package and used it in my company only. Tests could be used as a good document and essential for contributors. For the reason, I promised I will make it open source in the last kernel summit talk (https://linuxplumbersconf....