From: skannan@codeaurora.org (Saravana Kannan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support
Date: Thu, 22 Feb 2018 12:38:39 -0800 [thread overview]
Message-ID: <5A8F2A4F.5020105@codeaurora.org> (raw)
In-Reply-To: <20180222113352.oeedj7upx3zxvdcc@lakrids.cambridge.arm.com>
On 02/22/2018 03:33 AM, Mark Rutland wrote:
> On Wed, Feb 21, 2018 at 06:32:46PM -0800, Saravana Kannan wrote:
>> On 01/02/2018 03:25 AM, Suzuki K Poulose wrote:
>>> +static int dsu_pmu_event_init(struct perf_event *event)
>>> +{
>>> + struct dsu_pmu *dsu_pmu = to_dsu_pmu(event->pmu);
>>> +
>>> + if (event->attr.type != event->pmu->type)
>>> + return -ENOENT;
>>
>> You are checking if the caller set the attr.type "correctly".
>
> This is necessary for the case where perf_init_event() falls back to
> iterating over the list of PMUs, if event->attr.type wasn't found in the
> idr.
>
> Without this, we'd erroneously check events intended for other PMUs.
> So this is correct, and necessary.
Right, I'm aware of this. Which is why I also mentioned below that we
can't just blindly delete this.
>>> +static int dsu_pmu_device_probe(struct platform_device *pdev)
>
>>> + rc = perf_pmu_register(&dsu_pmu->pmu, name, -1);
>>
>> You are passing in -1 here. Which means the event type is assigned by the
>> perf framework. perf framework uses idr_alloc(&pmu_idr, ...) to get the id.
>> So the id assigned is going to depend on the probe order among the different
>> PMU drivers in the board/platform. So, this seems pretty random.
>
> The dynamic IDs are supposed to by looked up by name.
>
> Each PMU has a folder: /sys/bus/event_source/devices/$PMU
>
> ... with /sys/bus/event_source/devices/$PMU/type giving the type.
>
>> How is the caller supposed to know what to set the "type" to?
>
> The perf tools understand this already. If you do:
>
> perf stat -e $PMU/config=0xf00/
>
> ... they will look up the type for that PMU and use it automatically.
>
Ah, thanks! This finally explains how this is supposed to work from
userspace.
>> You also can't just delete the check in dsu_pmu_event_init() because the
>> event numbers you expose overlap with the per-CPU event numbers.
>
> The type check is necessary and cannot be deleted. It provides a
> namespace for the event IDs.
Right. Which is my point too.
>> I'm not exactly sure if we can add entries to perf_type_id. If that's
>> allowed maybe we need to add something line PERF_TYPE_DSU and use that?
>>
>> Or if that's not allowed then would it be better to offset the DSU PMU
>> events by some number (say 0x1000) and then delete the event type check or
>> pass PERF_TYPE_RAW to perf_pmu_register()?
>
> As above, neither of these should be necessary.
>
For the userspace interface. How about the kernel interface though?
perf_event_create_kernel_counter() takes attr.type as an input. But
there's no way to look up the DSU PMU's "type".
Thanks,
Saravana
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
WARNING: multiple messages have this Message-ID (diff)
From: Saravana Kannan <skannan@codeaurora.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>,
will.deacon@arm.com, robh@kernel.org, sudeep.holla@arm.com,
mathieu.poirier@linaro.org, peterz@infradead.org,
jonathan.cameron@huawei.com, linux-kernel@vger.kernel.org,
marc.zyngier@arm.com, leo.yan@linaro.org, frowand.list@gmail.com,
linux-arm-kernel@lists.infradead.org, avilaj@codeaurora.org
Subject: Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support
Date: Thu, 22 Feb 2018 12:38:39 -0800 [thread overview]
Message-ID: <5A8F2A4F.5020105@codeaurora.org> (raw)
In-Reply-To: <20180222113352.oeedj7upx3zxvdcc@lakrids.cambridge.arm.com>
On 02/22/2018 03:33 AM, Mark Rutland wrote:
> On Wed, Feb 21, 2018 at 06:32:46PM -0800, Saravana Kannan wrote:
>> On 01/02/2018 03:25 AM, Suzuki K Poulose wrote:
>>> +static int dsu_pmu_event_init(struct perf_event *event)
>>> +{
>>> + struct dsu_pmu *dsu_pmu = to_dsu_pmu(event->pmu);
>>> +
>>> + if (event->attr.type != event->pmu->type)
>>> + return -ENOENT;
>>
>> You are checking if the caller set the attr.type "correctly".
>
> This is necessary for the case where perf_init_event() falls back to
> iterating over the list of PMUs, if event->attr.type wasn't found in the
> idr.
>
> Without this, we'd erroneously check events intended for other PMUs.
> So this is correct, and necessary.
Right, I'm aware of this. Which is why I also mentioned below that we
can't just blindly delete this.
>>> +static int dsu_pmu_device_probe(struct platform_device *pdev)
>
>>> + rc = perf_pmu_register(&dsu_pmu->pmu, name, -1);
>>
>> You are passing in -1 here. Which means the event type is assigned by the
>> perf framework. perf framework uses idr_alloc(&pmu_idr, ...) to get the id.
>> So the id assigned is going to depend on the probe order among the different
>> PMU drivers in the board/platform. So, this seems pretty random.
>
> The dynamic IDs are supposed to by looked up by name.
>
> Each PMU has a folder: /sys/bus/event_source/devices/$PMU
>
> ... with /sys/bus/event_source/devices/$PMU/type giving the type.
>
>> How is the caller supposed to know what to set the "type" to?
>
> The perf tools understand this already. If you do:
>
> perf stat -e $PMU/config=0xf00/
>
> ... they will look up the type for that PMU and use it automatically.
>
Ah, thanks! This finally explains how this is supposed to work from
userspace.
>> You also can't just delete the check in dsu_pmu_event_init() because the
>> event numbers you expose overlap with the per-CPU event numbers.
>
> The type check is necessary and cannot be deleted. It provides a
> namespace for the event IDs.
Right. Which is my point too.
>> I'm not exactly sure if we can add entries to perf_type_id. If that's
>> allowed maybe we need to add something line PERF_TYPE_DSU and use that?
>>
>> Or if that's not allowed then would it be better to offset the DSU PMU
>> events by some number (say 0x1000) and then delete the event type check or
>> pass PERF_TYPE_RAW to perf_pmu_register()?
>
> As above, neither of these should be necessary.
>
For the userspace interface. How about the kernel interface though?
perf_event_create_kernel_counter() takes attr.type as an input. But
there's no way to look up the DSU PMU's "type".
Thanks,
Saravana
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2018-02-22 20:38 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-02 11:25 [PATCH v11 0/8] perf: Support for ARM DynamIQ Shared Unit Suzuki K Poulose
2018-01-02 11:25 ` Suzuki K Poulose
2018-01-02 11:25 ` [PATCH v11 1/8] perf: Export perf_event_update_userpage Suzuki K Poulose
2018-01-02 11:25 ` Suzuki K Poulose
2018-01-02 11:25 ` [PATCH v11 2/8] of: Add helper for mapping device node to logical CPU number Suzuki K Poulose
2018-01-02 11:25 ` Suzuki K Poulose
2018-01-02 11:25 ` Suzuki K Poulose
2018-01-02 11:25 ` [PATCH v11 3/8] coresight: of: Use of_cpu_node_to_id helper Suzuki K Poulose
2018-01-02 11:25 ` Suzuki K Poulose
2018-01-02 11:25 ` [PATCH v11 4/8] irqchip: gic-v3: " Suzuki K Poulose
2018-01-02 11:25 ` Suzuki K Poulose
2018-01-02 11:25 ` [PATCH v11 5/8] arm64: Use of_cpu_node_to_id helper for CPU topology parsing Suzuki K Poulose
2018-01-02 11:25 ` Suzuki K Poulose
2018-01-02 11:25 ` [PATCH v11 6/8] arm_pmu: Use of_cpu_node_to_id helper Suzuki K Poulose
2018-01-02 11:25 ` Suzuki K Poulose
2018-01-02 11:25 ` [PATCH v11 7/8] dt-bindings: Document devicetree binding for ARM DSU PMU Suzuki K Poulose
2018-01-02 11:25 ` Suzuki K Poulose
2018-01-02 11:25 ` Suzuki K Poulose
2018-01-02 11:25 ` [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support Suzuki K Poulose
2018-01-02 11:25 ` Suzuki K Poulose
2018-02-22 2:32 ` Saravana Kannan
2018-02-22 2:32 ` Saravana Kannan
2018-02-22 11:33 ` Mark Rutland
2018-02-22 11:33 ` Mark Rutland
2018-02-22 20:38 ` Saravana Kannan [this message]
2018-02-22 20:38 ` Saravana Kannan
2018-02-23 11:35 ` Mark Rutland
2018-02-23 11:35 ` Mark Rutland
2018-02-23 21:46 ` Saravana Kannan
2018-02-23 21:46 ` Saravana Kannan
2018-02-24 0:53 ` Saravana Kannan
2018-02-24 0:53 ` Saravana Kannan
2018-02-25 14:36 ` Mark Rutland
2018-02-25 14:36 ` Mark Rutland
2018-02-28 22:17 ` Saravana Kannan
2018-02-28 22:17 ` Saravana Kannan
2018-03-01 11:49 ` Mark Rutland
2018-03-01 11:49 ` Mark Rutland
2018-03-01 20:35 ` Saravana Kannan
2018-03-01 20:35 ` Saravana Kannan
2018-03-02 10:42 ` Mark Rutland
2018-03-02 10:42 ` Mark Rutland
2018-03-02 19:19 ` Saravana Kannan
2018-03-02 19:19 ` Saravana Kannan
2018-03-05 10:59 ` Mark Rutland
2018-03-05 10:59 ` Mark Rutland
2018-03-05 22:10 ` Saravana Kannan
2018-03-05 22:10 ` Saravana Kannan
2018-03-07 14:59 ` Suzuki K Poulose
2018-03-07 14:59 ` Suzuki K Poulose
2018-03-07 21:36 ` Saravana Kannan
2018-03-07 21:36 ` Saravana Kannan
2018-03-19 9:50 ` Suzuki K Poulose
2018-03-19 9:50 ` Suzuki K Poulose
2018-03-08 11:42 ` Mark Rutland
2018-03-08 11:42 ` Mark Rutland
2018-03-08 23:59 ` Saravana Kannan
2018-03-08 23:59 ` Saravana Kannan
2018-03-09 10:53 ` Suzuki K Poulose
2018-03-09 10:53 ` Suzuki K Poulose
2018-03-09 13:35 ` Mark Rutland
2018-03-09 13:35 ` Mark Rutland
2018-03-09 22:49 ` Saravana Kannan
2018-03-09 22:49 ` Saravana Kannan
2018-03-10 15:45 ` Mark Rutland
2018-03-10 15:45 ` Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5A8F2A4F.5020105@codeaurora.org \
--to=skannan@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.