Message-ID: <314f612d-d6e2-3855-44f1-d6cab756aac9@arm.com>
Date:   Fri, 13 Mar 2020 14:50:55 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Jonathan Cameron <Jonathan.Cameron@...wei.com>
Cc:     Qi Liu <liuqi115@...wei.com>, will@...nel.org,
        mark.rutland@....com, bhelgaas@...gle.com,
        linux-pci@...r.kernel.org, linuxarm@...wei.com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] perf:Add driver for HiSilicon PCIe PMU

On 2020-03-13 2:14 pm, Jonathan Cameron wrote:
> On Fri, 13 Mar 2020 13:23:53 +0000
> Robin Murphy <robin.murphy@....com> wrote:
> 
>> On 2020-03-12 12:06 pm, Qi Liu wrote:
>>> From: Qi liu <liuqi115@...wei.com>
>>>
>>> PCIe PMU Root Complex Integrate End Point(IEP) device is
>>> supported to sample bandwidth, latency, buffer occupation,
>>> bandwidth utilization etc.
>>> Each PMU IEP device monitors multiple root ports, and each
>>> IEP is registered as a pmu in /sys/bus/event_source/devices,
>>> so users can select the target IEP, and use filter to select
>>> root port, function and event.
>>> Filtering options are:
>>> event:    - select the event.
>>> subevent: - select the subevent.
>>> port:     - select target root port.
>>> func:     - select target EP device under the port.
>>>
>>> Example: hisi_pcie_00_14_00/event=0x08,subevent=0x04,   \
>>> port=0x05,func=0x00/ -I 1000
>>>
>>> PMU IEP device is described by its bus, device and function,
>>> target root port is 0x05 and target EP under it is function
>>> 0x00. Subevent 0x04 of event 0x08 is sampled.
>>>
>>> Note that in this RFC:
>>> 1. PCIe PMU IEP hardware is still in development.
>>> 2. Perf common event list is undetermined, and name of these
>>> events still need to be discussed.
>>> 3. port filter could only select one port each time.
>>> 4. There are two possible schemes of pmu registration, one is
>>> register each root port as a pmu, it is easier for users to
>>> select target port. The other one is register each IEP as pmu,
>>> for counters are per IEP, not per root port, the second scheme
>>> describes hardware PMC much more reasonable, but need to add
>>> "port" filter option to select port. We use the second one in
>>> this RFC.
>>>
> 
> Whilst it's great to have detailed feedback, just to make it clear...
> 
> This is an RFC for the reasons above.  They include that the hardware
> is still in development - i.e. we can't test it because they've not finished
> implementation yet.

That's OK - TBH I'd be more sympathetic if I wasn't still in the middle 
of developing a massively more complicated PMU driver for hardware that 
*does* exist, but that I only have sporadic access to one trivial 
configuration of :)

> The intention of posting so early is to get some feedback on the general
> approach and the specific points in 2,3 and 4 above.

It's probably hard to comment on point 2 until it's nailed down what 
actual events exist and what the values represent.

For point 3, there's a relatively intuitive way to support the case 
where all counters are affected by a single global filter - essentially, 
the first scheduled event 'claims' the global filter settings, then any 
further events have to have the same settings to be allowed in - we 
implement this in arm_smmuv3_pmu.c, for one example.

> The key fiddly point with this is that it is a shared PMU across a set
> of PCIe Root Ports (there are several of these devices on each SoC in
> the system covering a set of ports each).
> That makes for a somewhat fiddly interface, hence the RFC.
The general rule of thumb I've been told is that the granularity of "a 
PMU" usually wants to be the granularity at which you can start/stop 
multiple counters atomically (consider when you want to accurately 
measure a metric which requires relative values of two or more events). 
In that context, the structure implemented here looks like the right choice.

Robin.

> 
> Thanks to everyone who has reviewed though as definitely some stuff for liuqi to
> fix!
> 
> Jonathan
> 
> 

Powered by blists - more mailing lists