CoreSight October 2026

coresight@lists.linaro.org

7 participants
31 discussions

[PATCH v2 00/23] coresight: trbe: Refactor buffer and IRQ handling

by Leo Yan

This series follows the earlier TRBE buffer refactoring posting [1]. The work is now split into two parts. This first part contains fixes and refactoring in preparation for wrap and trigger mode support. Support for those modes will be sent separately. The patches are grouped as follows for easier review: Patches 1-5: Minor fixes Add register definitions, fix the watermark range check, and improve erratum checks and perf handle validation. Patches 6-11: Enable/disable lifecycle fixes Clean up session setup, status clearing and IRQ handle ownership. Patches 12-17: Refine status classification Decode stop reasons, report truncation on errors and improve trace-size accounting. Patches 18-23: Improve IRQ and overflow handling Keep the handle in per-CPU data, stabilize status reads, and improve AUX restarts and trace-gap reporting. A race also remains between TRBE interrupt handling and AUX pause/resume from a sampling NMI. This should be resolved as part of the state machine refactoring in the CoreSight AUX sampling series [2]. [1] https://lore.kernel.org/linux-arm-kernel/20251201-trbe_buffer_refactor_v1-1… [2] https://lore.kernel.org/linux-arm-kernel/20260915-arm_cs_support_aux_sample… Signed-off-by: Leo Yan <leo.yan(a)arm.com> --- Leo Yan (23): arm64/sysreg: Define TRBSR_EL1.EC event classes coresight: trbe: Make watermark range check overflow safe in __trbe_normal_offset() coresight: trbe: Use helpers for checking errata coresight: trbe: Check the buffer association before IRQ validation coresight: trbe: Validate perf handle before using sink data coresight: trbe: Drop redundant disable from enable path coresight: trbe: Publish the session after successful enable coresight: trbe: Clear stale external abort status coresight: trbe: Clear TRBSR status at stop sites coresight: trbe: Drop redundant disables coresight: trbe: Assign the perf handle in enable and disable coresight: trbe: Decode TRBSR status codes coresight: trbe: Simplify wrap status handling coresight: trbe: Treat access not allowed stops as fatal coresight: trbe: Report truncated trace on buffer update errors coresight: trbe: Always classify TRBSR when updating buffer coresight: trbe: Calculate trace size across buffer wrap coresight: trbe: Keep the perf handle in per-CPU data coresight: trbe: Reload the AUX buffer on overflow restart coresight: trbe: Add fault action argument to trbe_handle_overflow() coresight: trbe: Read TRBSR after prohibiting and flushing trace coresight: trbe: Restart trace source for stopped buffers coresight: trbe: Report trace gaps with PARTIAL instead of COLLISION arch/arm64/include/asm/sysreg.h | 6 + arch/arm64/tools/sysreg | 8 +- drivers/hwtracing/coresight/coresight-trbe.c | 481 ++++++++++++++++++--------- drivers/hwtracing/coresight/coresight-trbe.h | 8 - 4 files changed, 345 insertions(+), 158 deletions(-) --- base-commit: 343cfcbb3ecfdb80aa576a428cfa3b65ad783842 change-id: 20261016-trbe_enable_disable_irq_handle_refactor-0a3450f03473 Best regards, -- Leo Yan <leo.yan(a)arm.com>

6 days, 10 hours

[PATCH v4 00/10] coresight: Prevent per-thread events from sharing a sink

by James Clark

Concurrent per-thread events results in a WARN on N1SDP which leads to the realization that per-thread events shouldn't have been sharing sinks in the first place. This slips through because different per-thread events will have the same PID if owned by the same process, and we only check the PID and nothing else. That results in unexpected WARNs because it looks like we assumed it couldn't happen (although exclusive PMU rules allow it). But even if it was supported it would result in trace from the wrong thread in another event's per-thread buffer, so we should disallow it. Fix it by determining if sharing can happen at setup time. Then remove everywhere the same PID checking logic was copy pasted in each sink. The first three patches fix configuration initialization, AUX cleanup and topology locking. The remaining patches enforce the sharing rules and simplify the sink drivers. Signed-off-by: James Clark <james.clark(a)linaro.org> --- Changes in v4: - Count CPU sources in the registered topology and retain each sink's sharing classification until its last AUX session ends. - Serialize AUX topology access and provide locked and locking path release functions. - Reject unexpected path setup errors while retaining silent skips for missing ETMs and unreachable sinks. - Prevent all problematic sharing cases at aux setup rather than at runtime. (Leo) - Drop "coresight: tmc-etr: Don't stop Perf cleanup for active sysfs reads". It was a pre-existing bug and is even more unrelated now with the new model. - Remove workqueue rather than fix the lifecycle, its no longer needed. (Leo) - Add a getter for the config manager, cscfg_get_state(). (Leo) - Link to v3: https://lore.kernel.org/r/20260728-james-cs-multiple-per-threads-v3-0-6aee7… Changes in v3: - Storing and accessing event owners at runtime causes problems due to various scenarios of: events (and sibling events) exiting, children inheriting event FDs, PID reuse, CPU affine events that also have a target process set but different inherit settings. Fix it by creating a session ID in etm_setup_aux() and holding the references in it for the duration of the whole session. (Leo) - Make the ETR buffer allocator consistent with sink sharing rules by not doing numeric PID comparisons there either. - Fix up some Sashiko reports that it sees after interacting with cscfg and taking extra references to tasks and PIDs. - Link to v2: https://lore.kernel.org/r/20260709-james-cs-multiple-per-threads-v2-0-10ac7… Changes in v2: - Fix inherited events by following event->parent - Link to v1: https://lore.kernel.org/r/20260709-james-cs-multiple-per-threads-v1-0-d384e… --- James Clark (10): coresight: configfs: Don't assume active until cscfg_mgr is set coresight: etm-perf: Remove workqueue for freeing AUX data coresight: etm-perf: Serialize AUX topology access coresight: etm-perf: Reject event if building path fails coresight: etm-perf: Prevent sink sharing at setup time coresight: tmc-etr: Reflect new sharing rules in allocator coresight: tmc-etr: Remove sharing guards from ETR coresight: tmc-etf: Remove sharing guards from ETF coresight: etb10: Remove sharing guards from ETB10 coresight: ultrasoc-smb: Remove sharing guards from SMB drivers/hwtracing/coresight/coresight-core.c | 104 +++++++++++++++-- drivers/hwtracing/coresight/coresight-etb10.c | 28 +---- drivers/hwtracing/coresight/coresight-etm-perf.c | 119 ++++++++++--------- drivers/hwtracing/coresight/coresight-etm-perf.h | 2 - drivers/hwtracing/coresight/coresight-priv.h | 4 +- drivers/hwtracing/coresight/coresight-syscfg.c | 11 +- drivers/hwtracing/coresight/coresight-sysfs.c | 4 +- drivers/hwtracing/coresight/coresight-tmc-core.c | 6 +- drivers/hwtracing/coresight/coresight-tmc-etf.c | 22 +--- drivers/hwtracing/coresight/coresight-tmc-etr.c | 142 +++++++---------------- drivers/hwtracing/coresight/coresight-tmc.h | 16 +-- drivers/hwtracing/coresight/coresight-trace-id.c | 97 ++++++++++++++-- drivers/hwtracing/coresight/coresight-trace-id.h | 26 +++-- drivers/hwtracing/coresight/ultrasoc-smb.c | 20 +--- drivers/hwtracing/coresight/ultrasoc-smb.h | 3 - include/linux/coresight.h | 26 ++++- 16 files changed, 346 insertions(+), 284 deletions(-) --- base-commit: 343cfcbb3ecfdb80aa576a428cfa3b65ad783842 change-id: 20260708-james-cs-multiple-per-threads-ed1d25ed1734 Best regards, -- James Clark <james.clark(a)linaro.org>

6 days, 16 hours

[PATCH 0/2] perf: Order SPE and TRBE padding before publishing AUX head

by Leo Yan

SPE and TRBE write padding into their AUX buffers before advancing aux_head. Add the missing write barriers so that a userspace reader on another CPU cannot observe the new head before the padding stores become visible. AUX producers must make their data visible before publishing aux_head. The required synchronization depends on the trace hardware and CPU memory model, so the barriers belong in the drivers rather than in perf_aux_output_skip() or perf_aux_output_end(). The TRBE change also covers padding inserted by the overwrite erratum workaround before perf_aux_output_end(). Signed-off-by: Leo Yan <leo.yan(a)arm.com> --- Leo Yan (2): perf: arm_spe: Order padding before publishing AUX head coresight: trbe: Order padding before publishing AUX head drivers/hwtracing/coresight/coresight-trbe.c | 2 ++ drivers/perf/arm_spe_pmu.c | 5 ++++- 2 files changed, 6 insertions(+), 1 deletion(-) --- base-commit: 0fcb05b72344f40806cbe810de8872f1698bf053 change-id: 20261015-add_barriers_for_perf_aux_output_skip-70356815b2bd Best regards, -- Leo Yan <leo.yan(a)arm.com>

6 days, 17 hours

Re: [PATCH 1/5] dt-bindings: arm: coresight: Limit static replicator to atclk

by Leo Yan

On Tue, Oct 13, 2026 at 07:53:20AM +0200, Michal Simek wrote: > > > On 10/12/26 18:28, Leo Yan wrote: > > On Mon, Oct 12, 2026 at 02:35:37PM +0200, Michal Simek wrote: > > > > > > > > > On 10/2/26 17:07, Leo Yan wrote: > > > > Static replicators have no programmable registers and need no APB > > > > programming clock. > > > > > > > > The Zynq clock controller registers dbg_trc and dbg_apb and calls > > > > clk_prepare_enable() for each gate the bootloader left on. > > > > > > That's one bootloader behavior. If there is another bootloader that clocks > > > can be simply disabled. I don't think there is any reason to depends on > > > bootloader behavior. If there are clocks which has to be ON I can't see any > > > reason not to drive them. > > > > My reference to zynq_clk_setup() was to explain that this patch leaves > > the existing management of dbg_trc and dbg_apb unchanged. > > > > The CoreSight drivers do not request clocks named "dbg_trc" or "dbg_apb". > > And this is the point. DT binding is not describing what Linux driver handles. > Binding describes HW itself. I agreed that "Binding describes HW itself". The question is which hardware clock connections the DT properties describe. Arm DDI 0314H, Table B-1 [1], lists ATCLK for the replicator, and ATCLK and PCLKDBG for the trace funnel. The static modules have no APB programming interface. > And for proper functionality these 2 clocks need to be handled. Please point to the Zynq TRM section or clock diagram showing how dbg_trc and dbg_apb supply the replicator and funnel. > That Linux driver is not doing it that's different issue. My understanding is the CoreSight drivers have already followed spec to support clocks. [1] https://support.arm.com/documentation/ddi0314/h/CoreSight-Components-and-Cl…

6 days, 17 hours

Re: [PATCH 1/5] dt-bindings: arm: coresight: Limit static replicator to atclk

by Leo Yan

On Mon, Oct 12, 2026 at 02:35:37PM +0200, Michal Simek wrote: > > > On 10/2/26 17:07, Leo Yan wrote: > > Static replicators have no programmable registers and need no APB > > programming clock. > > > > The Zynq clock controller registers dbg_trc and dbg_apb and calls > > clk_prepare_enable() for each gate the bootloader left on. > > That's one bootloader behavior. If there is another bootloader that clocks > can be simply disabled. I don't think there is any reason to depends on > bootloader behavior. If there are clocks which has to be ON I can't see any > reason not to drive them. My reference to zynq_clk_setup() was to explain that this patch leaves the existing management of dbg_trc and dbg_apb unchanged. The CoreSight drivers do not request clocks named "dbg_trc" or "dbg_apb". And removing those unused clock properties introduces no additional dependence on the bootloader. Could you clarify how retaining these entries addresses the bootloader concern? > TRM page 741 > > Trace Port Clock The trace port clock is used to clock the TPIU and trace > buffer when the MIO interface is chosen and must be twice the frequency of > the desired TPIU clock. The TPIU clock frequency must be chosen to be fast > enough to allow the trace port to keep up with the amount of data being > traced, but slow enough to meet the dynamic characteristics of the data > output buffers of the TPIU. The quoted paragraph establishes a trace-clock requirement for the TPIU and trace buffer, how does it identify the clock inputs of the funnel and replicator? Thanks, Leo

1 week, 3 days

[GIT PULL] coresight: Update for linux v7.4

by Suzuki K Poulose

Hi Greg Please find the updates for coresight self hosted tracing subsystem targeting Linux v7.4. Apologies for the delay! Kindly pull. Suzuki The following changes since commit df2908090cda368b01ff43709f51890076c56157: Linux 7.3-rc2 (2026-09-06 15:07:20 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git tags/coresight-next-v7.4 for you to fetch changes up to 343cfcbb3ecfdb80aa576a428cfa3b65ad783842: coresight: tnoc: Constify amba_id table (2026-10-09 11:32:08 +0100) ---------------------------------------------------------------- coresight: updates for Linux v7.4 CoreSight selfhosted tracing subsystem updates for Linux v7.4, includes: - Separating the ETM configurations for sysfs and perf to avoid corrupting each other while in use - Hide sysfs control for TRBE as it is not supported - Constify Amba device table for tnoc Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> ---------------------------------------------------------------- James Clark (1): coresight: trbe: Hide enable_sink sysfs file Krzysztof Kozlowski (1): coresight: tnoc: Constify amba_id table Yeoreum Yun (14): coresight: etm4x: Prohibit TRCSEQSTR modifications while tracing enabled coresight: etm4x: prohibit modifying cntr_val while session is enabled coresight: etm3x: Prohibit modifying cntr_val while session is enabled coresight: etm4x: fix inconsistencies with sysfs configuration coresight: etm3x: fix inconsistencies with sysfs configuration coresight: etm3x: remove redundant cpu online check on etm_enable_sysfs() coresight: etm4x: introduce struct etm4_caps coresight: etm4x: exclude ss_status from drvdata->config coresight: etm4x: remove s_ex_level from config coresight: etm4x: rename local config as curr_config referring drvdata->curr_config coresight: etm4x: rename drvdata->config to sysfs_config coresight: etm3x: introduce struct etm_caps coresight: etm3x: rename local config as curr_config referring drvdata->curr_config coresight: etm3x: rename drvdata->config to sysfs_config drivers/hwtracing/coresight/coresight-config.c | 18 +- drivers/hwtracing/coresight/coresight-config.h | 22 + drivers/hwtracing/coresight/coresight-core.c | 1 + drivers/hwtracing/coresight/coresight-etm.h | 48 +- drivers/hwtracing/coresight/coresight-etm3x-core.c | 196 +++-- .../hwtracing/coresight/coresight-etm3x-sysfs.c | 461 +++++----- drivers/hwtracing/coresight/coresight-etm4x-cfg.c | 14 +- drivers/hwtracing/coresight/coresight-etm4x-core.c | 561 ++++++------ .../hwtracing/coresight/coresight-etm4x-sysfs.c | 961 +++++++++++---------- drivers/hwtracing/coresight/coresight-etm4x.h | 199 +++-- drivers/hwtracing/coresight/coresight-sysfs.c | 15 +- drivers/hwtracing/coresight/coresight-tnoc.c | 2 +- drivers/hwtracing/coresight/coresight-trbe.c | 7 + include/linux/coresight.h | 4 + 14 files changed, 1359 insertions(+), 1150 deletions(-)

1 week, 3 days

Re: [PATCH] coresight: tnoc: Constify amba_id table

by Suzuki K Poulose

On Sun, 05 Jul 2026 19:19:35 +0200, Krzysztof Kozlowski wrote: > Static 'struct amba_id' table is not modified so can be changed to const > for more safety. > > Applied, thanks! [1/1] coresight: tnoc: Constify amba_id table https://git.kernel.org/coresight/c/343cfcbb3ecf Best regards, -- Suzuki K Poulose <suzuki.poulose(a)arm.com>

1 week, 3 days

[PATCH v3 0/8] coresight: Prevent per-thread events from sharing a sink

by James Clark

Concurrent per-thread events results in a WARN on N1SDP which leads to the realization that per-thread events shouldn't have been sharing sinks in the first place. This slips through because different per-thread events will have the same PID if owned by the same process, and we only check the PID and nothing else. That results in unexpected WARNs because it looks like we assumed it couldn't happen (although exclusive PMU rules allow it). But even if it was supported it would result in trace from the wrong thread in another event's per-thread buffer, so we should disallow it. Fix it everywhere the same PID checking logic was copy pasted. Then the PIDs can be dropped from a few structs as they are now unused. Signed-off-by: James Clark <james.clark(a)linaro.org> --- Changes in v3: - Storing and accessing event owners at runtime causes problems due to various scenarios of: events (and sibling events) exiting, children inheriting event FDs, PID reuse, CPU affine events that also have a target process set but different inherit settings. Fix it by creating a session ID in etm_setup_aux() and holding the references in it for the duration of the whole session. (Leo) - Make the ETR buffer allocator consistent with sink sharing rules by not doing numeric PID comparisons there either. - Fix up some Sashiko reports that it sees after interacting with cscfg and taking extra references to tasks and PIDs. - Link to v2: https://lore.kernel.org/r/20260709-james-cs-multiple-per-threads-v2-0-10ac7… Changes in v2: - Fix inherited events by following event->parent - Link to v1: https://lore.kernel.org/r/20260709-james-cs-multiple-per-threads-v1-0-d384e… --- James Clark (8): coresight: tmc-etr: Don't stop Perf cleanup for active sysfs reads coresight: configfs: Don't assume active until cscfg_mgr is set coresight: etm-perf: Flush workqueue before unloading module coresight: tmc-etr: Prevent per-thread events from sharing a sink coresight: tmc-etr: Use session ID for buffer ownership coresight: tmc-etf: Prevent per-thread events from sharing a sink coresight: etb10: Prevent per-thread events from sharing a sink coresight: ultrasoc-smb: Prevent per-thread events from sharing a sink drivers/hwtracing/coresight/coresight-core.c | 28 +-- drivers/hwtracing/coresight/coresight-etb10.c | 33 ++-- drivers/hwtracing/coresight/coresight-etm-perf.c | 79 ++++++++- drivers/hwtracing/coresight/coresight-etm-perf.h | 15 ++ drivers/hwtracing/coresight/coresight-priv.h | 2 - drivers/hwtracing/coresight/coresight-syscfg.c | 6 +- drivers/hwtracing/coresight/coresight-tmc-core.c | 6 +- drivers/hwtracing/coresight/coresight-tmc-etf.c | 44 ++--- drivers/hwtracing/coresight/coresight-tmc-etr.c | 207 +++++++++++++---------- drivers/hwtracing/coresight/coresight-tmc.h | 30 ++-- drivers/hwtracing/coresight/coresight-trbe.c | 3 +- drivers/hwtracing/coresight/ultrasoc-smb.c | 25 +-- drivers/hwtracing/coresight/ultrasoc-smb.h | 6 +- include/linux/coresight.h | 5 +- 14 files changed, 294 insertions(+), 195 deletions(-) --- base-commit: 98495b5a4d77dd22e106f462b76e1093a55b29a7 change-id: 20260708-james-cs-multiple-per-threads-ed1d25ed1734 Best regards, -- James Clark <james.clark(a)linaro.org>

1 week, 6 days

Re: [PATCH 1/2] coresight: etm4x: Report whether the PMU counts external output 1

by Leo Yan

Hi Amir, Thanks for the patch. I have a few initial comments below. We may have further feedback after our internal review. On Wed, Sep 30, 2026 at 11:37:43PM -0700, Amir Ayupov wrote: [...] > #define CS_CFG_MATCH_CLASS_SRC_ALL 0x0001 /* match any source */ > #define CS_CFG_MATCH_CLASS_SRC_ETM4 0x0002 /* match any ETMv4 device */ > +/* ETM external output 1 is countable by the PMU as TRCEXTOUT1 */ > +#define CS_CFG_MATCH_CAP_PMU_EXTOUT1 0x0004 Do we need to tie this capability to TRCEXTOUT1? For example, Neoverse V2 exposes TRCEXTOUT0 through TRCEXTOUT3 as PMU events. > /* flags defining device instance matching - used in config match desc data. */ > #define CS_CFG_MATCH_INST_ANY 0x80000000 /* any instance of a class */ > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c > index e1a59b4345052..2847d2d7f7bed 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c > @@ -174,9 +174,14 @@ static int etm4_cfg_load_feature(struct coresight_device *csdev, > > int etm4_cscfg_register(struct coresight_device *csdev) > { > + struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent); > struct cscfg_csdev_feat_ops ops; > + u32 match_flags = CS_CFG_ETM4_MATCH_FLAGS; > > ops.load_feat = &etm4_cfg_load_feature; > > - return cscfg_register_csdev(csdev, CS_CFG_ETM4_MATCH_FLAGS, &ops); > + if (drvdata->pmu_extout1) > + match_flags |= CS_CFG_MATCH_CAP_PMU_EXTOUT1; > + > + return cscfg_register_csdev(csdev, match_flags, &ops); The current matching logic succeeds if a device and feature share any flag bit. If the feature sets both CS_CFG_MATCH_CLASS_SRC_ETM4 and CS_CFG_MATCH_CAP_PMU_EXTOUT1, it will still load on an ETM4 device that lacks the capability. Could we check the capability separately when loading the feature, perhaps in cscfg_load_feat_csdev(), and skip it on unsupported devices? > +static bool etm4_pmu_has_extout1(struct etmv4_drvdata *drvdata) > +{ > + int pmuver = read_pmuver(); > + > + if (!is_midr_in_range_list(etm4_pmu_extout1_cpus)) > + return false; Based on specific CPU variant, we should already have identified TRCEXTOUT has supported. So either we only base on MIDR list or we can figure out a reliable way to detect the feature dynamically. > + > + /* PMCEID0_EL0[63:32] describe events 0x4000-0x401f from PMUv3p1 */ > + if (!pmuv3_implemented(pmuver) || pmuver < ID_AA64DFR0_EL1_PMUVer_V3P1) > + return false; > + if (!(read_pmceid0() & BIT_ULL(32 + ARMV8_PMUV3_PERFCTR_TRCEXTOUT1 - > + ARMV8_PMUV3_EXT_COMMON_EVENT_BASE))) > + return false; > + > + /* nr_event is TRCIDR0.NUMEVENT, the number of events minus one */ > + return drvdata->nr_event >= 1; > +} [...] > @@ -1116,6 +1116,13 @@ int cscfg_csdev_enable_active_config(struct coresight_device *csdev, > > if (err) > cscfg_config_desc_put(config_desc); > + } else { > + /* > + * The configuration is active but was not loaded on this > + * device, for example because the device lacks a capability > + * its features require. Fail rather than trace without it. > + */ > + err = -EINVAL; > } This fixes a pre-existing issue. It is worther to put it in a separate patch with fixes tag: An early return would also avoid the normal enable path's indentation: if (!config_csdev_active) return -EINVAL; err = cscfg_csdev_enable_config(config_csdev_active, preset); ... Thanks, Leo

2 weeks

Re: [PATCH 2/2] perf: arm_spe: Prefer large AUX mappings

by Leo Yan

On Thu, Oct 01, 2026 at 08:16:09AM +0100, Will Deacon wrote: > On Wed, Sep 30, 2026 at 05:43:11PM +0100, Leo Yan wrote: > > How about adding a field to struct pmu to specify a preferred maximum > > page order for the AUX buffer? The perf core could try that order first > > and fall back to smaller orders if the allocation fails. > > I'm not sure that's thr right place for it, really. The driver has no > clue about whether it makes sense to use large contiguous mappings or > not, so I'd have thought that decision should be driven from userspace > (e.g. like MADV_HUGEPAGE) because it really depends on the user's > preference and isn't a fixed property of the hardware. Here MADV_HUGEPAGE cannot directly apply on this case: perf allocates the AUX pages during mmap, while TRBE accesses them through a separate kernel vmap() mapping. MADV_HUGEPAGE is applied after mmap, but a preference (or flag) would need to be specified before the AUX mmap. > > For example, the Neoverse V2 TRM documents: > > > > L1 Trace Buffer Extension (TRBE) TLB: 1 entry > > Wow, they really pulled out the stops for that implementation. I bet > we're supposed to be grateful for that entry! Yeah, Neoverse V3 was improved to have two entries. Even so, I was told it still suffers from TLB misses, so still needs a large mapping granule. > > Given the single L1 TRBE TLB entry, the TRBE driver could prefer > > PMD_ORDER (2 MiB with 4 KiB pages) to reduce TLB pressure. This reflects > > the hardware characteristic. > > > > This could be a trade-off instead of using PERF_PMU_CAP_AUX_PREFER_LARGE, > > avoiding large contiguous allocations that could reintroduce the Android > > OOM issue. I did a quick test with this approach and the results look > > positive. > > I really don't want the driver to second-guess userspace based on whatever > information it happens to have hard-coded about the specific CPU it's > running on. The kernel already takes the PERF_PMU_CAP_AUX_PREFER_LARGE flag from a PMU; a preferred maximum order would let the driver give it a bounded value. I do not intend to hard-code or guess a preference for a particular CPU variant. We can map TRBE or SPE buffer at PMD granularity. On a 4 KiB-page system, PMD_ORDER is order 9, or 2 MiB. Requesting a larger contiguous chunk cannot increase the mapping granule, so I would cap the preference there. It remains a preference: perf can fall back to smaller orders when allocation fails. Exposing the preference to userspace also seems problematic. Users generally lack the hardware details needed to choose an appropriate value. Even if tools provide a default, the same policy would need to be duplicated across perf, simpleperf, and proprietary tools. I don't think userspace tools are the right place for this policy. Thanks, Leo

2 weeks, 3 days

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight October 2026