From: Mark Rutland <mark.rutland@arm.com>
To: Kunkun Jiang <jiangkunkun@huawei.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 17:55:15 +0100 [thread overview]
Message-ID: <Y07acz161+tDtNUy@lakrids> (raw)
In-Reply-To: <d0b69c76-bfdb-e0c7-14a4-0f117ee000c7@huawei.com>
On Tue, Oct 18, 2022 at 09:53:09PM +0800, Kunkun Jiang wrote:
> 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?
We can't allcoate memory and so on during the onlining, and generally we
do not expect late hotplug of CPU types that weren't present during
boot (as e.g. errata handling won't work).
Thanks,
Mark.
>
> 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 16:56 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
2022-10-18 16:55 ` Mark Rutland [this message]
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=Y07acz161+tDtNUy@lakrids \
--to=mark.rutland@arm.com \
--cc=jiangkunkun@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--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