From: Akinobu Mita <akinobu.mita@gmail.com>
To: damon@lists.linux.dev
Cc: linux-perf-users@vger.kernel.org, sj@kernel.org, akinobu.mita@gmail.com
Subject: [RFC PATCH v3 0/4] mm/damon: introduce perf event based access check
Date: Thu, 23 Apr 2026 09:42:06 +0900 [thread overview]
Message-ID: <20260423004211.7037-1-akinobu.mita@gmail.com> (raw)
DAMON currently only provides PTE accessed-bit based access check, this
patch series adds a new perf event based access check.
Since perf event-based access checks do not require modifying the PTE
accessed-bit for pages representing each damon region, it reduces the
overhead of monitoring at a fixed granularity of the page size.
Here is a method and its results for comparing access checks using
existing access bits and new perf events.
The time required for the access check will be measured using the
following steps.
Start a memcached server with approximately 100GB of memory and run a
benchmark client.
```
# Run memcached as a daemon
memcached --daemon --pidfile=/tmp/memcached.pid --port=7777 \
--memory-limit=200000 --threads=8
# Load keys
memtier_benchmark -s 127.0.0.1 -p 7777 --key-maximum=100000000 \
--data-size=1000 --threads=8 --protocol=memcache_text \
--key-pattern=P:P --ratio=1:0 --requests=allkeys
# Run benchmark in the background
memtier_benchmark -s 127.0.0.1 -p 7777 --key-maximum=100000000 \
--data-size=1000 --threads=8 --protocol=memcache_text \
--key-pattern=Z:Z --ratio=50:50 --test-time=999999 --pipeline=10 \
--distinct-client-seed --randomize &> /tmp/memtier.log &
```
Measure the time required for access checks when monitoring memcached at
page size granularity.
Using accessed bit, prepare_access_checks takes 7 seconds and
check_accesses takes 5 seconds.
```
$ sudo $HOME/damo/damo start --ops vaddr \
--monitoring_intervals 5s 60s 300s \
--monitoring_nr_regions_range 1000000000 1000000000 \
--target_pid $(cat /tmp/memcached.pid)
$ sudo perf ftrace latency -a --hide-empty \
-T damon_va_prepare_access_checks -- sleep 60
# DURATION | COUNT | GRAPH |
1 - ... s | 4 | ############################################## |
# statistics (in usec)
total time: 28624961
avg time: 7156240
max time: 7322209
min time: 6859464
count: 4
$ sudo perf ftrace latency -a --hide-empty \
-T damon_va_check_accesses -- sleep 60
# DURATION | COUNT | GRAPH |
1 - ... s | 3 | ############################################## |
# statistics (in usec)
total time: 16007973
avg time: 5335991
max time: 5369579
min time: 5300285
count: 3
```
Using perf event, prepare_access_checks takes 0.01 seconds and
check_accesses takes 2.6 seconds.
```
$ sudo $HOME/damo/damo stop
$ sudo $HOME/damo/damo start --ops vaddr \
--perf_event 5000 0 0x4 0x1cd 0x1f 0 \
--monitoring_intervals 5s 60s 300s \
--monitoring_nr_regions_range 1000000000 1000000000 \
--target_pid $(cat /tmp/memcached.pid)
$ sudo perf ftrace latency -a --hide-empty \
-T kdamond_prepare_perf_event_report -- sleep 60
# DURATION | COUNT | GRAPH |
4 - 8 ms | 7 | ############################################## |
# statistics (in usec)
total time: 75641
avg time: 10806
max time: 11174
min time: 9945
count: 7
$ sudo perf ftrace latency -a --hide-empty \
-T kdamond_check_perf_event_reported_accesses -- sleep 60
# DURATION | COUNT | GRAPH |
1 - ... s | 7 | ############################################## |
# statistics (in usec)
total time: 18101248
avg time: 2585893
max time: 2834578
min time: 2504466
count: 7
$ kill $(cat /tmp/memcached.pid)
```
The time required for prepare_access_checks is proportional to the size of
the monitoring region when using the accessed bit, but it takes almost no
time when using the perf event as it only requires enabling it.
The time required for check_accesses is proportional to the size of the
monitoring region, regardless of whether you use the accessed bit or
perf-event.
This indicates that monitoring even larger memory ranges at page
granularity could take even longer.
However, when using perf-event, there is room in the future to make the
time proportional to the number of perf event samples by changing the
monitoring region management from an address-order linear list to a tree
structure.
It is important to note that with perf events, extra memory such as
sampling buffers needs to be allocated, and there is overhead due to perf
event interrupts (NMI) during the sampling interval.
Note: damo's --perf_event option
Using these features also requires modifications to damo, but these
are not included in this patch series and are currently under
development in the following branch:
* https://github.com/mita/damo/tree/damo-perf-for-v3.2.2
The option newly added to damo for perf event-based access check has the
following format:
`--perf_event <sample freq> <sample phys addr> <type> <config> <config1> <config2>`
- `sample freq`: A higher frequency improves access accuracy, but also
increases overhead.
- `sample phys addr`: specify 0 for vaddr and 1 for paddr.
- The remaining type, config, config1, and config2 settings can be found
as follows:
Run `perf mem record -vv` to obtain the log, and then find the part in
the log where `perf_event_open` was executed successfully.
```
$ sudo perf mem record -vv echo > /tmp/perf-mem-record.log 2>&1
$ cat /tmp/perf-mem-record.log
...
perf_event_attr:
type 4 (cpu)
size 144
config 0x1cd (mem_trans_retired.load_latency_gt_1024)
{ sample_period, sample_freq } 4000
sample_type IP|TID|TIME|ADDR|ID|PERIOD|DATA_SRC|WEIGHT_STRUCT
read_format ID|LOST
disabled 1
inherit 1
mmap 1
comm 1
freq 1
enable_on_exec 1
task 1
precise_ip 2
mmap_data 1
sample_id_all 1
mmap2 1
comm_exec 1
ksymbol 1
bpf_event 1
build_id 1
{ bp_addr, config1 } 0x1f
------------------------------------------------------------
sys_perf_event_open: pid 287986 cpu 0 group_fd -1 flags 0x8 = 5
...
```
The values for `type` and `config` are taken from this output.
Use the values of `config1` and `config2` if they are included in the log;
otherwise, set them to 0.
Any feedback or advice on the patch set would be greatly appreciated.
* RFC v3
- drop "reintroduce damon_operations->cleanup()" as no longer needed
- drop "allow user to set min size of region" (will be sent separately)
- add tgid to struct damon_access_report and use it instead of tid
- set perf_event_attr.precise_ip to 2
- prepare for the transition to report-based monitoring
- switch to use access_reported in struct damon_region
- switch to use sample/primitives/perf_events sysfs directory
* RFC v2: https://lore.kernel.org/damon/20260309010009.11639-1-akinobu.mita@gmail.com/T/
- reintroduce damon_operations->cleanup()
- introduce struct damon_access_report
- use struct damon_access_report instead of introducing struct
damon_perf_record
- remove maximum region size setting
* RFC v1: https://lore.kernel.org/damon/20260123021014.26915-1-akinobu.mita@gmail.com/T/
* TODO
- Integrate into report-based monitoring
- Explain actual usage examples and test results
- Send the necessary patches to damo
- Set maybe_corrupted when it detects that a useless perf_event has
been specified.
- Check if it works in a virtual environment using vPMU
Akinobu Mita (4):
mm/damon/core: add code borrowed from report-based monitoring work
mm/damon/core: add common code for perf event based access check
mm/damon/vaddr: support perf event based access check
mm/damon/paddr: support perf event based access check
.../ABI/testing/sysfs-kernel-mm-damon | 8 +
include/linux/damon.h | 102 ++
mm/damon/core.c | 113 ++-
mm/damon/ops-common.h | 59 ++
mm/damon/paddr.c | 41 +
mm/damon/sysfs.c | 872 +++++++++++++++++-
mm/damon/vaddr.c | 506 ++++++++++
7 files changed, 1697 insertions(+), 4 deletions(-)
--
2.43.0
next reply other threads:[~2026-04-23 0:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 0:42 Akinobu Mita [this message]
2026-04-23 0:42 ` [RFC PATCH v3 1/4] mm/damon/core: add code borrowed from report-based monitoring work Akinobu Mita
2026-04-23 1:21 ` sashiko-bot
2026-04-23 0:42 ` [RFC PATCH v3 2/4] mm/damon/core: add common code for perf event based access check Akinobu Mita
2026-04-23 1:58 ` sashiko-bot
2026-04-23 0:42 ` [RFC PATCH v3 3/4] mm/damon/vaddr: support " Akinobu Mita
2026-04-23 2:48 ` sashiko-bot
2026-04-23 0:42 ` [RFC PATCH v3 4/4] mm/damon/paddr: " Akinobu Mita
2026-04-23 3:22 ` sashiko-bot
2026-04-23 4:34 ` [RFC PATCH v3 0/4] mm/damon: introduce " SeongJae Park
2026-04-24 3:27 ` Akinobu Mita
2026-04-24 23:31 ` SeongJae Park
2026-04-25 12:33 ` Akinobu Mita
2026-04-25 15:33 ` SeongJae Park
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260423004211.7037-1-akinobu.mita@gmail.com \
--to=akinobu.mita@gmail.com \
--cc=damon@lists.linux.dev \
--cc=linux-perf-users@vger.kernel.org \
--cc=sj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox