[RFC PATCH v4 0/9] mm/damon: hardware-sampled access reports

[Liew Rui Yan <aethernet65535@gmail.com>]

Hi Ravi,


TLDR
====

I have noticed that there might have an issue with this patch or my CPU.
I am not sure.  I have provided some details below.

On Mon, 05 Oct 2026 01:46:44 -0700 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:

> This series lets DAMON monitor a hardware-sampled data attribute -- the
> addresses a PMU saw accessed -- through the data attributes monitoring
> (probe) interface, and run DAMOS schemes on it in data attributes-only
> mode.  Patches 3, 5, and 6 are co-developed with Akinobu Mita, building
> on his earlier perf-event proposal [3].
> 

I expected it to monitor regions in the same way as PTE sampling, that
is, if the system has hot memory, DAMON should be able to detect it, or
at least with some probability.  However, it is not always work like
that.  After I starting DAMON about 10 minutes, the DAMON cannot found
any hot page, even when I am running 'stress-ng --vm 6 --vm-bytes 6G':

    snapshot time: [0 ns, 100 ms] (100 ms)
    |0000000000000000000000000000000000000000| size 1.461 GiB   access 0      age 3 m 3.200 s  
                                   |000000000| size 1.465 GiB   access 0      age 3 m 1 s      
                                          |00| size 2.922 GiB   access 0      age 3 m 0.500 s  
                         |0000000000000000000| size 1.471 GiB   access 0      age 3 m 1.700 s  
                    |000000000000000000000000| size 1.462 GiB   access 0      age 3 m 2.100 s  
                                          |00| size 1.470 GiB   access 0      age 3 m 0.500 s  
                                           |0| size 2.926 GiB   access 0      age 3 m 0.400 s  
                                          |00| size 1.544 GiB   access 0      age 3 m 0.500 s  
    memory bw estimate: 0 B per second
    total size: 14.722 GiB
    record DAMON intervals: sample 5 ms, aggr 100 ms

    Note that this is my own fork of damo [1].

To ensure this was not a bug in my damo fork [1], I adding a tracing
statistic [2] to DAMON to confirm whether this was indeed a DAMON issue.

TLDR for new tracing statsistic: 'seen' means how many times
damon_perf_overflow() was called.

Later, I noticed that about 10 minutes after starting DAMON, the 'seen'
stopped increasing:

    I am running 'stress-ng --vm 6 --vm-bytes 6G' during recording this
    statistic.

    Start Time: 19:25:42 | End Time: 19:42:18
    Time Unit: 1 step = 1.81 minutes

       Seen (Delta)
            ^
            |
      100k  |  *
      36k   |      *
      18k   |                      *           *
      17k   |          *
      15k   |                  *
      4k    |                          *
      453   |                              *
      106   |              *
        0   |                                      *
            +--+---+---+---+---+---+---+---+---+---+---> Step
               1   2   3   4   5   6   7   8   9   10

    Note: Zero delta from 19:42:18 (step 10) till 20:00:00 (I close my
    machine after that).

My DAMON Perf Config
====================

    K=/sys/kernel/mm/damon/admin/kdamonds/0
    C=$K/contexts/0
    P=$C/monitoring_attrs/probes

    echo 1 > $P/0/preps/nr_preps
    echo perf_event > $P/0/preps/0/prep_action
    cat /sys/bus/event_source/devices/ibs_op/type > $P/0/preps/0/type
    echo 0 > $P/0/preps/0/config
    echo 0 > $P/0/preps/0/config2
    echo 0 > $P/0/preps/0/sample_freq
    echo 100000 > $P/0/preps/0/sample_period
    echo 1 > $P/0/preps/0/sample_phys_addr
    echo 0 > $P/0/preps/0/exclude_kernel
    echo 0 > $P/0/preps/0/exclude_hv
    echo 1 > $P/0/weight

    Note that this issue can also reproduce even when
    'kernel.perf_cpu_time_max_percent=100'.

My CPU Specification
====================

    CPU(s):                                  12
    On-line CPU(s) list:                     0-11
    Vendor ID:                               AuthenticAMD
    Model name:                              AMD Ryzen 5 5600H with Radeon Graphics
    CPU family:                              25
    Model:                                   80
    Thread(s) per core:                      2
    Core(s) per socket:                      6
    Socket(s):                               1
    Stepping:                                0
    Microcode version:                       0xa500012
    Frequency boost:                         enabled
    CPU(s) scaling MHz:                      48%
    CPU max MHz:                             4280.9849
    CPU min MHz:                             412.6250
    BogoMIPS:                                6587.34

I am trying to figure out if this is a CPU issue, or if there is an
issue with this patch.  I would be happy to provide more information.

[...]

[1] https://github.com/aethernet65535/damo/tree/probe
[2] Trace patch diff
'''
diff --git a/include/trace/events/damon.h b/include/trace/events/damon.h
index 4dfc9467ea4b..290d3ee2d836 100644
--- a/include/trace/events/damon.h
+++ b/include/trace/events/damon.h
@@ -199,6 +199,23 @@ TRACE_EVENT(damon_aggregated,
 			__entry->nr_accesses, __entry->age)
 );
 
+TRACE_EVENT(damon_perf_source_stats,
+
+	TP_PROTO(unsigned long seen),
+
+	TP_ARGS(seen),
+
+	TP_STRUCT__entry(
+		__field(unsigned long, seen)
+	),
+
+	TP_fast_assign(
+		__entry->seen = seen;
+	),
+
+	TP_printk("seen=%lu", __entry->seen)
+)
+
 #endif /* _TRACE_DAMON_H */
 
 /* This part must be outside protection */
diff --git a/mm/damon/core.c b/mm/damon/core.c
index bae4569f0ab3..73988ce82b1a 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -4927,6 +4927,8 @@ static void kdamond_check_reported_accesses(struct damon_ctx *ctx)
 	if (damon_drains_ring_perf(ctx))
 		__kdamond_drain_ring(ctx, tbl, ctx->perf_rings,
 				&ctx->perf_pending);
+
+	trace_damon_perf_source_stats(damon_get_perf_seen());
 }
 
 /*
diff --git a/mm/damon/perf_source.c b/mm/damon/perf_source.c
index 4baa8aebcfa8..e8365dbe1744 100644
--- a/mm/damon/perf_source.c
+++ b/mm/damon/perf_source.c
@@ -27,6 +27,8 @@ struct damon_perf_probe_state {
 	struct perf_event *single_event;
 };
 
+static DEFINE_PER_CPU(unsigned long, damon_perf_seen);
+
 static void damon_perf_overflow(struct perf_event *perf_event,
 				struct perf_sample_data *data,
 				struct pt_regs *regs)
@@ -40,6 +42,8 @@ static void damon_perf_overflow(struct perf_event *perf_event,
 		.cpu = smp_processor_id(),
 	};
 
+	this_cpu_inc(damon_perf_seen);
+
 	/*
 	 * Teardown NULLs event->ctx (with a release barrier) before releasing
 	 * the per-CPU perf events, so an in-flight overflow racing the
@@ -84,6 +88,16 @@ static void damon_perf_overflow(struct perf_event *perf_event,
 	damon_report_access(&report);
 }
 
+unsigned long damon_get_perf_seen(void)
+{
+	unsigned long sum = 0;
+	int cpu;
+
+	for_each_possible_cpu(cpu)
+		sum += per_cpu(damon_perf_seen, cpu);
+	return sum;
+}
+
 static enum cpuhp_state damon_perf_cpuhp_state;
 
 /*
diff --git a/mm/damon/perf_source.h b/mm/damon/perf_source.h
index 12ca61be7243..49beca6e3189 100644
--- a/mm/damon/perf_source.h
+++ b/mm/damon/perf_source.h
@@ -50,6 +50,7 @@ int damon_perf_probe_setup(struct damon_ctx *ctx,
 			   struct damon_perf_probe_event *event);
 void damon_perf_probe_teardown(struct damon_ctx *ctx,
 			       struct damon_perf_probe_event *event);
+unsigned long damon_get_perf_seen(void);
 
 #endif /* CONFIG_DAMON_PERF_SOURCE */
 #endif /* _DAMON_PERF_SOURCE_H */
'''

Best regards,
Rui Yan