From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 88721C433FE for ; Tue, 18 Oct 2022 16:56:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=aph9Sy/2pzfUme5RyFHgH/xzIKzgkkCIaGg0AK+JK94=; b=htvbF5hqiCB+k0 R3uC3PJCbPeJ6qPE/FUSKTK2DokbT4pVXuMR7MUI3xAJxzRGBkmW1nFe2hXsJ2nPNDCI4rGHmptFL mHRcWC2DuDFeY/tIsdB1kWTHRsai3gLwRn1F44oJR8YmMSYY8g9tphYR8GJYdbGSv3/didgGe8NKU hTf/ki80XE04gl3ySKhfar6BW3YYLNe/EboxViBoqwBlT3TfsZMlgtjSfnfxvbTJJqsVNtEHuzE7R ZfLx+5bnED+pUsiM9EXomvHhnbMdFAMPCaBzJPnsQkQyRGu0eSzOLqRUR/9NQiPhMhIQbbu98Bngx JLVgPLGSqxQdgxp3Riyw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1okpsD-0099J5-7l; Tue, 18 Oct 2022 16:55:25 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1okps8-0099F5-Dm for linux-arm-kernel@lists.infradead.org; Tue, 18 Oct 2022 16:55:22 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4C4D7113E; Tue, 18 Oct 2022 09:55:25 -0700 (PDT) Received: from lakrids (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DBC733F7D8; Tue, 18 Oct 2022 09:55:17 -0700 (PDT) Date: Tue, 18 Oct 2022 17:55:15 +0100 From: Mark Rutland To: Kunkun Jiang Cc: pierre.gondois@arm.com, valentin.schneider@arm.com, vschneid@redhat.com, will@kernel.org, "moderated list:ARM SMMU DRIVERS" , Zenghui Yu , "wanghaibin.wang@huawei.com" , "wangyanan (Y)" Subject: Re: [PATCH 0/3] arm_pmu: acpi: avoid allocations in atomic context Message-ID: References: <20220930111844.1522365-1-mark.rutland@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221018_095520_576547_5DC50064 X-CRM114-Status: GOOD ( 19.55 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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