On Tue, Mar 04, 2025 at 11:25:06AM +0000, Catalin Marinas wrote: > On Mon, Mar 03, 2025 at 10:44:21AM -0600, Rob Herring wrote: > > On Sat, Mar 1, 2025 at 1:05 AM Will Deacon <will@xxxxxxxxxx> wrote: > > > On Tue, 18 Feb 2025 14:39:55 -0600, Rob Herring (Arm) wrote: > > > > This series enables perf branch stack sampling support on arm64 via a > > > > v9.2 arch feature called Branch Record Buffer Extension (BRBE). Details > > > > on BRBE can be found in the Arm ARM[1] chapter D18. > > > > > > > > I've picked up this series from Anshuman. v19 and v20 versions have been > > > > reworked quite a bit by Mark and myself. The bulk of those changes are > > > > in patch 11. > > > > > > > > [...] > > > > > > Applied cleanups to will (for-next/perf), thanks! > > > > > > [01/11] perf: arm_pmuv3: Call kvm_vcpu_pmu_resync_el0() before enabling counters > > > https://git.kernel.org/will/c/04bd15c4cbc3 > > > [02/11] perf: arm_pmu: Don't disable counter in armpmu_add() > > > https://git.kernel.org/will/c/dcca27bc1ecc > > > [03/11] perf: arm_pmuv3: Don't disable counter in armv8pmu_enable_event() > > > https://git.kernel.org/will/c/4b0567ad0be5 > > > [04/11] perf: arm_v7_pmu: Drop obvious comments for enabling/disabling counters and interrupts > > > https://git.kernel.org/will/c/7a5387748215 > > > [05/11] perf: arm_v7_pmu: Don't disable counter in (armv7|krait_|scorpion_)pmu_enable_event() > > > https://git.kernel.org/will/c/7bf1001e0d91 > > > [06/11] perf: apple_m1: Don't disable counter in m1_pmu_enable_event() > > > https://git.kernel.org/will/c/c2e793da59fc > > > [07/11] perf: arm_pmu: Move PMUv3-specific data > > > https://git.kernel.org/will/c/dc4d58a752ea > > > > I don't know if you looked at the thread on patch 11 and said "long > > discussion, I'll assume a new version is coming. Next!" because that's > > what I would do. In this case though, there's not any changes. > > I do this as well ;). But I think Will is waiting for Mark R to look at > the rest of the series. Sorry for the delay there. I'm happy with the structure of this; my only remaining concern is the filtering logic, as it is surprisingly subtle, and when I was last working on that it wasn't clear to me whether we could alwways filter appropriately (or whether it'd be better to reject scheduling of events with mismatched filters). I'll try to page that in and properly attack that soon, but aside from that concern the series as a whole looks good to me. Thanks, Mark.
