Re: [PATCH 1/2] perf/arm-cmn: Cope with spurious IRQs better

From: Geoff Blake
Date: Wed Nov 30 2022 - 11:07:20 EST


Robin,

>From my perspective, this is a worse solution as now we're sweeping an
issue under the rug and consuming CPU cycles handling IRQs we should not
be getting in the first place. While an overflow IRQ from the cmn should
not be high frequency, there is a non-zero chance in the future it could
be and this could lead to a very hard to debug performance issue instead
of the current problem, which is discovering we need to clean up better
from a noisy kernel message.

The driver as best I can grok currently is optimized to limit the amount
of register writes for the common use-case, which is setting and unsetting
events, so all the wiring for the PMU to feed events to the DTC is done up
front on load: DTC_CTL's DT_EN bit is set immediately during probe, as is
OVFL_INTR_EN. All the DN states and DTM PMU_CONFIG_PMU_EN is deferred
for when an event is actually set, and here we go through all of them
anyways for each event unless its bynodeid, so the expense of setting
events grows linearly with the mesh size anyways.

Doing a one time scan on remove/shutdown to reset everything to a
clean state seems like a wash performance wise and wanting to keep just a
single register write doesn't make much sense to me.

Should I instead pull this step out as a
generic initialization step that can live as a single chunk of code to
make it better for maintainability? Would that be a better solution?

- Geoff