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.
2024 2024-04-17: The third in-person DAMON meetup has held as a unconference session of Open Source Summint North America 2024
2024-04-03: Oracle released a tool that helps finding distros that enabled DAMON
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).
2022년 마지막 날을 맞아, 저의 간단하고 버그가 많은 스크립트와[1] github 을 통해 저의 오픈소스 커밋 통계를 내봤습니다.
리눅스 커널 통계 리눅스 커널의 메모리 관리 서브시스템과 커널 전체의 2022년 통계를 위해 제 버그 많은 스크립트를[1] 아래와 같이 돌려 봤습니다.
메모리 관리 서브시스템 2022년 한해, 305명의 사람들이 리눅스 커널 메모리 관리 서브시스템 개발에 참여해 81,631 라인의 변경을 2,135 개 커밋으로 만들었습니다.
변경한 라인 수와 커밋 갯수 기준으로 저는 그 305명 가운데 두번째와 (10,537 라인) 세번째로 (106 커밋) 큰 변경을 만들었군요.
KernelSummit'21 에서 DAMON/DAMOS 를 발표하게 되었습니다. 발표 제목은 “Writing a fine-grained access pattern-oriented lightweight kernel module using DAMON/DAMOS in 10 minutes” 입니다.
https://linuxplumbersconf.org/event/11/contributions/984/
DAMON[0] 이 프로파일링만을 위한 건 아니지만, DAMON 을 프로파일링에 활용하는 방법에 대한 괜찮은 직관적 예를 여태 소개한 적이 없다는 걸 깨달았습니다. 간단하지만 현실적인 DAMON 의 프로파일링 도구로써의 사용법은 모니터링 결과를 콜스택과 함께 기록한 후 시간대에 맞춰 시각화 하는 것입니다.
예를 들어, 아래 그림은 SPLASH-2X 벤치마크의 ‘fft’ 라는 워크로드에 대한 그런 시각화 결과입니다. 여기서, 우린 이 워크로드에 세개의 폭발적 메모리 액세스가 이루어지는 구간이 있는 것을 알 수 있으며, FFT1DOnce.cons::prop.2() 가 그 첫번째와 두번째 구간에, 그리고 Transpose() 는 세번째 구간에 연관되어 있음을 알 수 있습니다.
DAMON 은 kselftest 와 kunit 에 기반한 여러 테스트를 자신의 패치셋에 포함시켜 두고 있습니다. 커널 트리에 위치하는 테스트는 짧은 수행시간만 가지는게 바람직하므로, 시간을 오래 소요하는 테스트들을 패키지화 해서 저희 회사 내에서만 사용해 오고 있었습니다. 테스트는 좋은 문서로 사용될 수 있고 컨트리뷰터들에게도 필요하죠. 그런 이유로, 이 패키지를 오픈소스로 만들겠다고 지난 커널 서밋 발표에서 이야기 했었습니다 (https://linuxplumbersconf.org/event/7/contributions/659/).
어제, 이 패키지 를 마침내 GPL v2 라이센스의 오픈소스로 릴리즈 했습니다. 이제 DAMON 인터페이스를 이해하고 여러분의 기계 위에서 스스로 DAMON 을 테스트 하는데 이 패키지를 사용하실 수 있습니다.
DAMON 소개를 위한 웹사이트[1] 를 열었습니다.
DAMON 공식 문서[2], 실제에 가까운 여러 워크로드의 힙[3], mmap() 된 영역[4], 그리고 스택[5] 에 대한 히트맵 포맷의 동적 액세스 패턴들, 동적 워킹셋 사이즈의 분포[6] 와 시간대에 따른 워킹셋 사이즈의 변화양상[7], 그리고 성능 테스트 결과[8] 를 확인해 보실 수 있습니다.
[1] https://damonitor.github.io
[2] https://damonitor.github.io/doc/html/latest
[3] https://damonitor.github.io/test/result/visual/latest/heatmap.0.html
[4] https://damonitor.github.io/test/result/visual/latest/heatmap.1.html
[5] https://damonitor.github.io/test/result/visual/latest/heatmap.2.html
[6] https://damonitor.github.io/test/result/visual/latest/wss_sz.html
[7] https://damonitor.github.io/test/result/visual/latest/wss_time.html
[8] https://damonitor.github.io/test/result/perf/latest/html/index.html
With increasingly data-intensive workloads and limited DRAM capacity, optimal memory management based on dynamic access patterns is becoming increasingly important. Such mechanisms are only possible if accurate and efficient dynamic access pattern monitoring is available.
DAMON is a Data Access MONitoring framework subsystem for the Linux kernel developed for such memory management. It is designed with some key mechanism (refer to Design for the detail) that make it
accurate (the monitoring output is useful enough for DRAM level memory management; It might not be appropriate for CPU Cache levels, though), light-weight (the monitoring overhead is low enough to be applied online), and scalable (the upper-bound of the overhead is in constant range regardless of the size of target workloads).