On Mon, Aug 10, 2026 at 04:10:48PM +0100, Will Deacon wrote:
> On Mon, Aug 10, 2026 at 03:44:42PM +0100, Leo Yan wrote:
> > Commit 18049c8cff9c ("perf/aux: Allocate non-contiguous AUX pages by
> > default") made the AUX allocator use order-0 pages by default unless a
> > PMU explicitly asks for contiguous allocations.
>
> But that commit specifically calls out SPE as benefitting from
> non-contiguous pages:
>
> "For instance, ARM SPE and TRBE operate with virtual pages, and
> Coresight ETR allocates a separate buffer. For these PMUs,
> allocating contiguous AUX pages unnecessarily exacerbates memory
> fragmentation. This fragmentation can prevent their use on
> long-running devices."
>
> so why doesn't passing PERF_PMU_CAP_AUX_PREFER_LARGE reintroduce the
> problems that 18049c8cff9c was trying to solve?
The question is how "allocating contiguous AUX pages unnecessarily
exacerbates memory fragmentation." The relevant information I could find
is [1]:
"On Android, we collect ETM data periodically on internal user devices
for AutoFDO optimization (for both userspace libraries and the
kernel). Allocating a large chunk of contiguous AUX pages (4M for each
CPU) periodically is almost unbearable. The kernel may need to kill
many processes to fulfill the request. It affects user experience even
after using PMU."
We might have missed chance to clarify how the fragmentation issue
occurs in the first place. Let's say, a phone with 8 CPUs, allocating
4MB per CPU requires 32MB in total, which is a relatively small
portion of 4GiB or 8GiB of RAM commonly found in phones. Moreover, once
contiguous pages are freed, the buddy allocator can coalesce them
again into buddy list. It is not obvious to me that PREFER_LARGE
directly causes fragmentation.
One case where AUX allocation could exacerbate fragmentation is when the
system is already fragmented. If a high-order allocation fails and the
allocator falls back to smaller-order blocks, those allocations may
consume free blocks scattered across different buddy regions and make
subsequent high-order allocations more difficult.
If this is the main concern, I'd suggest using a smaller AUX buffer
(e.g. 1MB or even 512KB) for TRBE/SPE to reduce memory pressure.
Snapshot mode '-S' could also be considered, as it allows the buffer to
be allocated once and reused for subsequent recordings by signals.
OTOH, using only order-0 pages can significantly increase TTW overhead
on the trace path and lead to overflows, we observe this causes huge
trace discontinuity. In the end, we need to trace-off the fragmentation
concern against the trace discontinuity.
Thanks,
Leo
[1] https://lore.kernel.org/lkml/CALJ9ZPNLgEBxOmDim-vztUknEETwdL-Z2gJ8K9s44TiPg…
On Sun, Aug 30, 2026 at 08:09:12PM -0700, Randy Dunlap wrote:
> kernel-doc reports 2 (kernel-doc) lines in coresight.h that don't have
> a beginning '*' in them, so fix these lines.
>
> Also convert struct coresight_trace_id_map to kernel-doc format to
> remove another warning.
>
> Warning: include/linux/coresight.h:173 bad line:
> connected to @src_port. NULL until the device is created
> Warning: include/linux/coresight.h:177 bad line:
> needs to be filtered.
> Warning: include/linux/coresight.h:236 This comment starts with '/**',
> but isn't a kernel-doc comment.
>
> Fixes: ec9903d6cc34 ("coresight: Add support for trace filtering by source")
> Fixes: d49c9cf15f89 ("coresight: Rename connection members to make the direction explicit")
> Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org>
Reviewed-by: Leo Yan <leo.yan(a)arm.com>
Thanks to Tamas Petz for noticing that Arm CoreSight perf data can contain
many PERF_RECORD_ITRACE_START records.
PERF_RECORD_ITRACE_START provides the decoder with the initial thread
context when that information is absent from the trace stream. Once
tracing has started, Arm SPE and CoreSight decoders track subsequent
context changes using context packets or recorded sched_switch events.
Have both drivers call perf_event_itrace_started() after successfully
starting event. This prevents perf core from emitting redundant
PERF_RECORD_ITRACE_START records when an event is scheduled in again.
Since the Arm SPE and CoreSight drivers can be built as modules, export
perf_event_itrace_started() before using it in those drivers.
This series was verified with Arm CoreSight using the commands below.
The perf data contains 100 sched_switch events but only one
PERF_RECORD_ITRACE_START record:
taskset -c 2 perf record -e cs_etm//u -e sched:sched_switch -- \
taskset -c 2 bash -c 'while true; do sleep 0.01; done'
^C
perf script -D 2>&1 | grep -c sched_switch
100
perf script -D 2>&1 | grep -c PERF_RECORD_ITRACE_START
1
Signed-off-by: Leo Yan <leo.yan(a)arm.com>
---
Leo Yan (3):
perf/core: Export perf_event_itrace_started()
perf: arm_spe: Suppress redundant ITRACE start records
coresight: perf: Suppress ITRACE start records
drivers/hwtracing/coresight/coresight-etm-perf.c | 2 ++
drivers/perf/arm_spe_pmu.c | 2 ++
kernel/events/core.c | 1 +
3 files changed, 5 insertions(+)
---
base-commit: 786262be6048deab760f68c8acc2c85607165894
change-id: 20260901-perf_suppress_itrace_start_records-42faf45e9ce9
Best regards,
--
Leo Yan <leo.yan(a)arm.com>
