From: Suzuki K Poulose <Suzuki.Poulose@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, marc.zyngier@arm.com,
will.deacon@arm.com, catalin.marinas@arm.com, robh@kernel.org,
sudeep.holla@arm.com, peterz@infradead.org,
mathieu.poirier@linaro.org, leo.yan@linaro.org,
frowand.list@gmail.com, Jonathan.Cameron@huawei.com,
devicetree@vger.kernel.org
Subject: Re: [PATCH v9 8/8] perf: ARM DynamIQ Shared Unit PMU support
Date: Fri, 3 Nov 2017 14:34:30 +0000 [thread overview]
Message-ID: <bea99cb3-5f4b-962f-2d8d-c2b2364db651@arm.com> (raw)
In-Reply-To: <20171103122035.7jvgpn434thjoufr@lakrids.cambridge.arm.com>
On 03/11/17 12:20, Mark Rutland wrote:
> Hi Suzuki,
>
> This looks good, but there are a couple of edge cases I think that we
> need to handle, as noted below.
>
> On Tue, Oct 31, 2017 at 05:23:18PM +0000, Suzuki K Poulose wrote:
>> Changes since V8:
>
>> - Fill in the "module" field for the PMU to prevent the module unload
>> when the PMU is active.
>
> Huh. For some reason I thought that was done automatically, but having
> looked, I see that it is not.
>
> It looks like this is missing from the SPE PMU, and the CCN PMU. Would
> you mind fixing those up?
>
> The only other PMU that I see affected is the AMD power PMU; I've pinged
> the maintainer separately.
>
> [...]
>
>> +The driver also exposes the CPUs connected to the DSU instance in "associated_cpus".
>
> Just to check, is there a user of this?
>
> I agree that it could be useful, but AFAICT the perf tool won't look at
> this, so it seems odd to expose it. I'd feel happier punting on exposing
> that so that we can settle on a common name for this across
> uncore/system PMUs.
It allows the user to identify the DSU instance to profile if there are
multiple DSUs on the system. Also this information can be used to identify
the "cpu" list that can be provided for -C option.
>
> [...]
>
>> +static void dsu_pmu_probe_pmu(void *data)
>> +{
>
>> + /* We can only support upto 31 independent counters */
>
> Nit: s/upto/up to/
>
> [...]
>
>> +static void dsu_pmu_init_pmu(struct dsu_pmu *dsu_pmu)
>> +{
>> + int cpu, rc;
>> +
>> + cpu = dsu_pmu_get_online_cpu(dsu_pmu);
>> + /* Defer, if we don't have any active CPUs in the DSU */
>> + if (cpu >= nr_cpu_ids)
>> + return;
>> + rc = smp_call_function_single(cpu, dsu_pmu_probe_pmu, dsu_pmu, 1);
>> + if (rc)
>> + return;
>> + /* Reset the interrupt overflow mask */
>> + dsu_pmu_get_reset_overflow();
>> + dsu_pmu_set_active_cpu(cpu, dsu_pmu);
>> +}
>
> I think this can be simplified by only callnig this in the hotplug
> callback, and not donig the corss-call at all at driver init time. That
> way, we can do:
>
> static void dsu_pmu_init_pmu(struct dsu_pmu *dsu_pmu)
> {
> if (dsu_pmu->num_counters == -1)
> dsu_pmu_probe_pmu(dsu_pmu);
>
> dsu_pmu_get_reset_overflow();
> }
>
> ... which also means we can simplify the prototype of
> dsu_pmu_probe_pmu().
>
> Note that the dsu_pmu_set_active_cpu() can be factored out to the
> caller, which is a little clearer, as I suiggest below.
>
>> +static int dsu_pmu_device_probe(struct platform_device *pdev)
>> +{
>
>> + /*
>> + * We could defer probing the PMU details from the registers until
>> + * an associated CPU is online.
>> + */
>> + dsu_pmu_init_pmu(dsu_pmu);
>
> ... then we can drop this line ...
>
>> + platform_set_drvdata(pdev, dsu_pmu);
>> + rc = cpuhp_state_add_instance(dsu_pmu_cpuhp_state,
>> + &dsu_pmu->cpuhp_node);
>
> ... as this should set things up if a CPU is already online.
>
> [...]
Got it, thats a good idea. I will change it.
>
>> +static int dsu_pmu_cpu_online(unsigned int cpu, struct hlist_node *node)
>> +{
>> + struct dsu_pmu *dsu_pmu = hlist_entry_safe(node, struct dsu_pmu,
>> + cpuhp_node);
>> +
>> + if (!cpumask_test_cpu(cpu, &dsu_pmu->associated_cpus))
>> + return 0;
>> +
>> + /* Initialise the PMU if necessary */
>> + if (dsu_pmu->num_counters < 0)
>> + dsu_pmu_init_pmu(dsu_pmu);
>> + /* Set the active CPU if we don't have one */
>> + if (cpumask_empty(&dsu_pmu->active_cpu))
>> + dsu_pmu_set_active_cpu(cpu, dsu_pmu);
>> + return 0;
>> +}
>
> I don't think this is quite right, as if we've offlined all the
> associated CPUs, the DSCU itself may have been powered down, and we'll
> want to reset it when it's brought online.
>
> I think we want this to be:
>
> static int dsu_pmu_cpu_online(unsigned int cpu, struct hlist_node *node)
> {
> struct dsu_pmu *dsu_pmu = hlist_entry_safe(node, struct dsu_pmu,
> cpuhp_node);
>
> if (!cpumask_test_cpu(cpu, &dsu_pmu->associated_cpus))
> return 0;
>
> /* If the PMU is already managed, there's nothing to do */
> if (!cpumask_empty(&dsu_pmu->active_cpu))
> return 0;
>
> /* Reset the PMU, and take ownership */
> dsu_pmu_init_pmu(dsu_pmu);
> dsu_pmu_set_active_cpu(cpu, dsu_pmu);
>
> return 0;
> }
>
> [...]
>
>> +static int dsu_pmu_cpu_teardown(unsigned int cpu, struct hlist_node *node)
>> +{
>
>> + dsu_pmu_set_active_cpu(dst, dsu_pmu);
>> + perf_pmu_migrate_context(&dsu_pmu->pmu, cpu, dst);
>
> In other PMU drivers, we do the migrate, then set the active CPU. That
> shouldn't matter, but for consistency, could we flip these around?
OK, will flip it.
>
> Otherwise, this looks good to me.
>
> With the above changes:
>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Thanks for the review. I will post the updated version.
Suzuki
prev parent reply other threads:[~2017-11-03 14:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-31 17:23 [PATCH v9 0/8] perf: Support for ARM DynamIQ Shared Unit Suzuki K Poulose
2017-10-31 17:23 ` [PATCH v9 1/8] perf: Export perf_event_update_userpage Suzuki K Poulose
2017-11-03 11:16 ` Mark Rutland
2017-10-31 17:23 ` [PATCH v9 2/8] of: Add helper for mapping device node to logical CPU number Suzuki K Poulose
2017-10-31 17:23 ` [PATCH v9 3/8] coresight: of: Use of_cpu_node_to_id helper Suzuki K Poulose
2017-10-31 17:23 ` [PATCH v9 4/8] irqchip: gic-v3: " Suzuki K Poulose
2017-10-31 17:23 ` [PATCH v9 5/8] arm64: Use of_cpu_node_to_id helper for CPU topology parsing Suzuki K Poulose
2017-10-31 17:23 ` [PATCH v9 6/8] arm_pmu: Use of_cpu_node_to_id helper Suzuki K Poulose
2017-10-31 17:23 ` [PATCH v9 7/8] dt-bindings: Document devicetree binding for ARM DSU PMU Suzuki K Poulose
2017-10-31 17:23 ` [PATCH v9 8/8] perf: ARM DynamIQ Shared Unit PMU support Suzuki K Poulose
2017-11-03 12:20 ` Mark Rutland
2017-11-03 14:34 ` Suzuki K Poulose [this message]
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=bea99cb3-5f4b-962f-2d8d-c2b2364db651@arm.com \
--to=suzuki.poulose@arm.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=catalin.marinas@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=leo.yan@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=mathieu.poirier@linaro.org \
--cc=peterz@infradead.org \
--cc=robh@kernel.org \
--cc=sudeep.holla@arm.com \
--cc=will.deacon@arm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®