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 215D9C433FE for ; Fri, 30 Sep 2022 11:21:04 +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=uuVdSR5m8J5kQNQtwyeFQ/f2Rg0ji+S531zT8Yul8Ik=; b=p6vtvd8jOCjUQT sBVByTGj+ZNGIkW1HM8WsMH5w7v+g18PUFUQ0ff+DnITk+MjyldTzAuBCgF1Q3QvGspk4IE9UYUCL lsLf2ntNu9sqrGAA2DTz++Hii1ewFkRvCLzPWDp8CNgWpq9lTorYKJWgD89O73Kf7FKIzt0fw4qDd JZitTeCKUQTP8NT+BsAWtXBqspZLR3HCVHyqdiysG1RubIY9gPiBoYrftvqTQ2IznaeLeuCAhSMWX mwp6fNI1sA4ZFTFDO25p4OZYV+y1pJ0haaTVTxvouiS2zcL/iTwGPSLaUEVN9sPQyww96xflkCUmz zeN9rRGbmp9k4LEgxzDQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oeE3i-008oKL-01; Fri, 30 Sep 2022 11:19:58 +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 1oeE3b-008oGr-8Q for linux-arm-kernel@lists.infradead.org; Fri, 30 Sep 2022 11:19:53 +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 F2F9B244B; Fri, 30 Sep 2022 04:19:55 -0700 (PDT) Received: from FVFF77S0Q05N (unknown [10.57.81.185]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E18C73F73B; Fri, 30 Sep 2022 04:19:47 -0700 (PDT) Date: Fri, 30 Sep 2022 12:19:42 +0100 From: Mark Rutland To: Pierre Gondois Cc: linux-kernel@vger.kernel.org, Dietmar Eggemann , Valentin Schneider , Thomas Gleixner , Sebastian Andrzej Siewior , Will Deacon , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v1 1/1] arm_pmu: acpi: Pre-allocate pmu structures Message-ID: References: <20220912155105.1443303-1-pierre.gondois@arm.com> <20220912155105.1443303-2-pierre.gondois@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-20220930_041951_434730_1978AECB X-CRM114-Status: GOOD ( 35.18 ) 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 Fri, Sep 30, 2022 at 10:01:12AM +0200, Pierre Gondois wrote: > On 9/29/22 17:56, Mark Rutland wrote: > > On Thu, Sep 29, 2022 at 04:08:19PM +0200, Pierre Gondois wrote: > > The big problem here is that while we can detect those PMUs late, we only > > register them with the core perf code in arm_pmu_acpi_probe(), so even if we > > detect PMUs after that, those PMUs won't become usable. > > > > I don't think we can support the case where none of the CPUs associated with a > > PMU are booted at startup unless we make more substantial changes to the way we > > register the PMUs with perf (and that would be going firther than what we > > support with DT). > > > > We can support bringing those CPUs online, just not registering them with perf. > > > > > I tried the patch on a Juno-r2 with the 'maxcpus=1 apci=force' parameters. When late > > > hotplugging CPU1 (which has a different pmu than CPU0), no pmu structure is found and > > > the cpuhp state machine fails (since arm_pmu_acpi_cpu_starting() failed). > > > > Ah, sorry, I missed that returning an error here would completely halt bringing > > the CPU online. We arm_pmu_acpi_cpu_starting() to return 0 rather than -ENOENT > > when it doesn't find a matching PMU, which would permit the CPU to come online. > > > > I've made that change (and pushed that out to the branch), and it seems to work > > for me, testing in a UEFI+ACPI VM on a ThunderX2, with the arm_pmu_acpi code > > hacked to use the cpu index (rather than the MIDR) as the identifier for the > > type of CPU. > > > > With that change, booting a 64-vCPU VM with 'maxcpus=8', I see each of the > > boot-time CPUs had its PMU registered: > > > > | # 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 > > > > ... and if I try to online a non-matching CPU the CPU will come up, but I get a > > notification that we couldn't associate with a PMU: > > > > | # 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] > > > > If I do the same thing but without the MIDR hack, it also seems to work: > > > > | # 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 > > > > ... so I think that should be ok? > > Ok yes, thanks for the explanation. I tried it aswel and everything > was as expected.Just some typos: Great! > patch 1: > factor out PMU<->CPU assocition > -> association > A subsequeqnt patch will rework the ACPI probing of PMUs, and we'll need > -> subsequent > > patch 2: > A subsequeqnt patch will rework the ACPI probing of PMUs, and we'll need > -> subsequent > > patch 3: > The current ACPI PMU probing logic tries to aassociate PMUs with CPUs > works. The arm_pmu_acpi_cpu_starting() callback only tries to assocaite > though we will now warn when we cannot assocaite a CPU with a PMU. > -> associate (for the 3 lines) Sorry; those were particularly typo-ridden. Thanks for the corrections! I'll send these out as a series shortly. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel