On Thu, Jun 19, 2025 at 02:57:55PM +0100, Mark Rutland wrote:
> On Tue, Jun 17, 2025 at 12:36:18PM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 17, 2025 at 07:27:50PM +0900, Koichi Okuno wrote:
> > > + pcipmu->pmu = (struct pmu) {
> > > + .parent = dev,
> > > + .task_ctx_nr = perf_invalid_context,
> > > +
> > > + .pmu_enable = fujitsu_pci__pmu_enable,
> > > + .pmu_disable = fujitsu_pci__pmu_disable,
> > > + .event_init = fujitsu_pci__event_init,
> > > + .add = fujitsu_pci__event_add,
> > > + .del = fujitsu_pci__event_del,
> > > + .start = fujitsu_pci__event_start,
> > > + .stop = fujitsu_pci__event_stop,
> > > + .read = fujitsu_pci__event_read,
> > > +
> > > + .attr_groups = fujitsu_pci_pmu_attr_grps,
> > > + .capabilities = PERF_PMU_CAP_NO_EXCLUDE,
> >
> > Should these drivers not also have PERF_PMU_CAP_NO_INTERRUPT ? Per them
> > being uncore they cannot generate samples.
>
> These PMUs actually have an interrupt, so that might be a bit confusing.
> That said, the counters seem to be 64-bit, so the interrupt doesn't seem
> practically necessary today.
Yeah, I saw they had an interrupt. But them being uncore they must not
sample, and NO_INTERRUPT means not being able to sample.
Naming urgh :-)
> Either way, the fujitsu_pci__event_init() function rejects sampling
> events, so it correctly rejects sampling events.
>
> IMO, it'd be a bit nicer to do the inverse, and have the perf core
> reject sampling events by default for non-CPU PMUs.
Yeah, there's lots of cleanup to be done. Quite possibly also some
unification between the various drivers.
Just need someone that knows what they're doing that has spare time,
know anybody like that? :-)
