From: Kunkun Jiang <jiangkunkun@huawei.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: <pierre.gondois@arm.com>, <valentin.schneider@arm.com>,
<vschneid@redhat.com>, <will@kernel.org>,
"moderated list:ARM SMMU DRIVERS"
<linux-arm-kernel@lists.infradead.org>,
Zenghui Yu <yuzenghui@huawei.com>,
"wanghaibin.wang@huawei.com" <wanghaibin.wang@huawei.com>,
"wangyanan (Y)" <wangyanan55@huawei.com>
Subject: Re: [PATCH 0/3] arm_pmu: acpi: avoid allocations in atomic context
Date: Tue, 18 Oct 2022 21:53:09 +0800 [thread overview]
Message-ID: <d0b69c76-bfdb-e0c7-14a4-0f117ee000c7@huawei.com> (raw)
In-Reply-To: <20220930111844.1522365-1-mark.rutland@arm.com>
Hi Mark:
On 2022/9/30 19:18, Mark Rutland wrote:
> I've tested the series in a VM, using ACPI and faked MIDR values to test
> a few homogeneous and heterogeneous configurations, using the 'maxcpus'
> kernel argument to test the late-hotplug behaviour:
I did the same test as you(without this series) and encountered the same
problem.
Nice to see this series while asking for help in the community. But why not
register their own CPU PMU for late hotplugged cpus with a unique MIDR?
Are there
any restrictions here?
Thanks,
Kunkun Jiang
>
> * On a system where all CPUs have the same MIDR, late-onlining a CPU causes it
> to be associated with a matching PMU:
>
> | # ls /sys/bus/event_source/devices/
> | armv8_pmuv3_0 breakpoint software tracepoint
> | # cat /sys/bus/event_source/devices/armv8_pmuv3_0/cpus
> | 0-7
> | # echo 1 > /sys/devices/system/cpu/cpu10/online
> | Detected PIPT I-cache on CPU10
> | GICv3: CPU10: found redistributor a region 0:0x00000000081e0000
> | GICv3: CPU10: using allocated LPI pending table @0x00000000402b0000
> | CPU10: Booted secondary processor 0x000000000a [0x431f0af1]
> | # ls /sys/bus/event_source/devices/
> | armv8_pmuv3_0 breakpoint software tracepoint
> | # cat /sys/bus/event_source/devices/armv8_pmuv3_0/cpus
> | 0-7,10
>
> * On a system where all CPUs have a unique MIDR, each of the boot-time
> CPUs gets a unique PMU:
>
> | # ls /sys/bus/event_source/devices/
> | armv8_pmuv3_0 armv8_pmuv3_3 armv8_pmuv3_6 software
> | armv8_pmuv3_1 armv8_pmuv3_4 armv8_pmuv3_7 tracepoint
> | armv8_pmuv3_2 armv8_pmuv3_5 breakpoint
>
> * On a system where all CPUs have a unique MIDR, late-onlining a CPU
> results in that CPU not being associated with a PMU, but the CPU is
> successfully onlined:
>
> | # echo 1 > /sys/devices/system/cpu/cpu8/online
> | Detected PIPT I-cache on CPU8
> | GICv3: CPU8: found redistributor 8 region 0:0x00000000081a0000
> | GICv3: CPU8: using allocated LPI pending table @0x0000000040290000
> | Unable to associate CPU8 with a PMU
> | CPU8: Booted secondary processor 0x0000000008 [0x431f0af1]
>
> Thanks,
> Mark.
>
> Mark Rutland (3):
> arm_pmu: acpi: factor out PMU<->CPU association
> arm_pmu: factor out PMU matching
> arm_pmu: rework ACPI probing
>
> drivers/perf/arm_pmu.c | 17 +-----
> drivers/perf/arm_pmu_acpi.c | 113 ++++++++++++++++++++---------------
> include/linux/perf/arm_pmu.h | 1 -
> 3 files changed, 69 insertions(+), 62 deletions(-)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-10-18 13:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-30 11:18 [PATCH 0/3] arm_pmu: acpi: avoid allocations in atomic context Mark Rutland
2022-09-30 11:18 ` [PATCH 1/3] arm_pmu: acpi: factor out PMU<->CPU association Mark Rutland
2022-09-30 11:18 ` [PATCH 2/3] arm_pmu: factor out PMU matching Mark Rutland
2022-09-30 11:18 ` [PATCH 3/3] arm_pmu: rework ACPI probing Mark Rutland
2022-11-07 19:10 ` Will Deacon
2022-11-08 9:42 ` Mark Rutland
2022-09-30 14:45 ` [PATCH 0/3] arm_pmu: acpi: avoid allocations in atomic context Pierre Gondois
2022-10-18 13:53 ` Kunkun Jiang [this message]
2022-10-18 16:55 ` Mark Rutland
2022-11-07 19:08 ` Will Deacon
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=d0b69c76-bfdb-e0c7-14a4-0f117ee000c7@huawei.com \
--to=jiangkunkun@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=pierre.gondois@arm.com \
--cc=valentin.schneider@arm.com \
--cc=vschneid@redhat.com \
--cc=wanghaibin.wang@huawei.com \
--cc=wangyanan55@huawei.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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