Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp12801719rwl; Tue, 3 Jan 2023 21:56:24 -0800 (PST) X-Google-Smtp-Source: AMrXdXu5gMcAWs77ny4hJbEuU8WtdCX5LsO0+oAVXGZ35Tjm22qIUrKXWI6AJlepqZmeDeZ17eBq X-Received: by 2002:a17:906:9c85:b0:7c1:27a:80ed with SMTP id fj5-20020a1709069c8500b007c1027a80edmr40409762ejc.0.1672811784490; Tue, 03 Jan 2023 21:56:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672811784; cv=none; d=google.com; s=arc-20160816; b=Ky+iXRcJ1qz98sX3ZAYOXRnJWH6TyfNwjBufEGHYpbekwIFlIIL8/T0A/sBKo2Ah42 0V3E8vMhC6DAzjNt8T1pZyEZdkSB+aaiK4r/DGPuFHqSMd+FuNRDEQL1zBeo1F6SC85D eA3N2B2l7tUFCOVtUMBtX3eqvwy4RpC2g9qKo+TcI9Eq4na2dZFpuMwYqKAFplxajhPN r8cmAywxZcPQ3s4eTTfUkOWRnLMcmGduiuVrxUK+GRyQmmVND6fAbGteIYQD+lIYfdA9 76dddvKqH+nd8l76NEuu48Cz9otZaEKCyUKh9vfUA1inlEPVUzYtI0nfRsIhQjr0QSOt mPKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :content-language:accept-language:in-reply-to:references:message-id :date:thread-index:thread-topic:subject:cc:to:from; bh=lpqSrn0G37BHnCxFVJ+LnUYzKmG6t/K/SAyY7lrqttg=; b=Zq8EU1R8FdIeeHPjdtHOC71Ji1MfwGQuoY3+XKpuV/jgsSrEH+V2uRs+EUPknXuZOV e6Wlw81oSzqg5tUiubbRN9gvxWFFRaqGb1NrIIuCtOBYcEh7Xu7Z8C7DpIxXZYtZzNMw 6ge9dZczq2G/86/7tOvWedv7mCZtRmtkNrwtsGZ+SIQyFWfAkYzzWr5DjlStr2KhEogV 3+2HdXb+7IdTzx8D1NO4C0ZqmpewHEETsXrL5u1MiJ5eaqLJDi2qgct+ISrOhgeazene TNLb9oqxrKWdmE03MrEkWLNodStAojMGiIZH81B33eQTjBQ2ml4nawOx9pnU0hXsFx72 ke1g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qq18-20020a17090720d200b007882936242fsi22499618ejb.769.2023.01.03.21.56.10; Tue, 03 Jan 2023 21:56:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230303AbjADFfs convert rfc822-to-8bit (ORCPT + 57 others); Wed, 4 Jan 2023 00:35:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57838 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229508AbjADFfr (ORCPT ); Wed, 4 Jan 2023 00:35:47 -0500 Received: from ex01.ufhost.com (ex01.ufhost.com [61.152.239.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 74B78165B2 for ; Tue, 3 Jan 2023 21:35:44 -0800 (PST) Received: from EXMBX166.cuchost.com (unknown [175.102.18.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "EXMBX166", Issuer "EXMBX166" (not verified)) by ex01.ufhost.com (Postfix) with ESMTP id EFB6024E311; Wed, 4 Jan 2023 13:35:41 +0800 (CST) Received: from EXMBX163.cuchost.com (172.16.7.73) by EXMBX166.cuchost.com (172.16.6.76) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Wed, 4 Jan 2023 13:35:42 +0800 Received: from EXMBX161.cuchost.com (172.16.6.71) by EXMBX163.cuchost.com (172.16.6.73) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Wed, 4 Jan 2023 13:35:41 +0800 Received: from EXMBX161.cuchost.com ([fe80::f152:b9a3:2243:db3c]) by EXMBX161.cuchost.com ([fe80::f152:b9a3:2243:db3c%15]) with mapi id 15.00.1497.044; Wed, 4 Jan 2023 13:35:41 +0800 From: Leyfoon Tan To: Conor Dooley , Sudeep Holla CC: Andrew Jones , Palmer Dabbelt , Paul Walmsley , Albert Ou , "linux-riscv@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Ley Foon Tan Subject: RE: [PATCH] riscv: Move call to init_cpu_topology() to later initialization stage Thread-Topic: [PATCH] riscv: Move call to init_cpu_topology() to later initialization stage Thread-Index: AQHZH0BUA1ZpH2MfF0y2uzSNVn9yRK6MUX9QgAAVqICAATb70A== Date: Wed, 4 Jan 2023 05:35:41 +0000 Message-ID: <672440143ab04d3dbcc6de0a16bab3e1@EXMBX161.cuchost.com> References: <20230103035316.3841303-1-leyfoon.tan@starfivetech.com> <20230103065411.2l7k6r57v4phrnos@orel> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [202.188.176.82] x-yovoleruleagent: yovoleflag Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > -----Original Message----- > From: Conor Dooley > Sent: Wednesday, 4 January, 2023 1:08 AM > To: Leyfoon Tan ; Sudeep Holla > > Cc: Andrew Jones ; Palmer Dabbelt > ; Paul Walmsley ; Albert > Ou ; linux-riscv@lists.infradead.org; linux- > kernel@vger.kernel.org; Ley Foon Tan > Subject: Re: [PATCH] riscv: Move call to init_cpu_topology() to later > initialization stage > > Hello! > > Couple comments for you. > > +CC Sudeep: I've got a question for you below. > > On Tue, Jan 03, 2023 at 07:53:38AM +0000, Leyfoon Tan wrote: > > > From: Andrew Jones > > > Subject: Re: [PATCH] riscv: Move call to init_cpu_topology() to > > > later initialization stage On Tue, Jan 03, 2023 at 11:53:16AM +0800, > > > Ley Foon Tan wrote: > > > > topology_parse_cpu_capacity() is failed to allocate memory with > > > > kcalloc() after read "capacity-dmips-mhz" DT parameter in CPU DT > > Uhh, so where did this "capacity-dmips-mhz" property actually come from? > I had a quick check of qemu with grep & I don't see anything there that > would add this property. > This property should not be valid on anything other than arm AFAICT. This DT parameter is not in default Qemu. I've added it for testing (see test steps in below). This is preparation to support asymmetric CPU topology for RISC-V. > > > > > nodes. This > > > > topology_parse_cpu_capacity() is called from init_cpu_topology(), > > > > move call to init_cpu_topology() to later initialization stage > > > > (after memory allocation is available). > > > > > > > > Note, this refers to ARM64 implementation, call > > > > init_cpu_topology() in smp_prepare_cpus(). > > > > > > > > Tested on Qemu platform. > > > > > > Hi Ley, > > > > > > Can you provide the topologies (command lines) tested? > > 2 clusters with 2 CPU cores each. > > What's the actual commandline for this? I'm not the best with QEMU, so it'd > really be appreciated, given the above. I used the Qemu to dump the DTS for 'virt' machine from Qemu, then add the "capacity-dmips-mhz" DT parameter and modify the CPU topology for clusters. 1. Dump the dtb for 'virt' machine: qemu-system-riscv64 -cpu rv64 -smp 4 -m 2048M -M virt,dumpdtb=qemu_virt.dtb 2. Convert dtb to dts dtc -I dtb -O dts qemu_virt.dtb > qemu_virt.dts 3. Modifying qemu_virt.dts 4. Compile dts to dtb dtc -I dts -O dtb qemu_virt.dts > qemu_virt.dtb 5. Pass in "-dtb qemu_virt.dtb" as one of Qemu's argument. > > > > > Signed-off-by: Ley Foon Tan > > > > > > Fixes tag? > > Okay, will send out next revision with Fixes tag. > > Please don't just send versions to add tags, Palmer can pick them up if/when > he applies the patch. Okay. Will let Palmer add tag below if he applies the patch. Fixes: 03f11f03dbfe ("RISC-V: Parse cpu topology during boot. ") > > > > > arch/riscv/kernel/smpboot.c | 3 ++- > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/arch/riscv/kernel/smpboot.c > > > > b/arch/riscv/kernel/smpboot.c index 3373df413c88..ddb2afba6d25 > > > > 100644 > > > > --- a/arch/riscv/kernel/smpboot.c > > > > +++ b/arch/riscv/kernel/smpboot.c > > > > @@ -39,7 +39,6 @@ static DECLARE_COMPLETION(cpu_running); > > > > > > > > void __init smp_prepare_boot_cpu(void) { > > > > - init_cpu_topology(); > > > > } > > > > > > > > void __init smp_prepare_cpus(unsigned int max_cpus) @@ -48,6 > > > > +47,8 > > > @@ > > > > void __init smp_prepare_cpus(unsigned int max_cpus) > > > > int ret; > > > > unsigned int curr_cpuid; > > > > > > > > + init_cpu_topology(); > > I know arm64 does this, but there is any real reason for us to do so? > @Sudeep, do you know why arm64 calls that each time? > Or if it is worth "saving" that call on riscv, since arm64 is clearly happily calling > it for many years & calling it later would likely head off a good few allocation > issues (like the one we saw with the topology reworking a few months ago). > > Thanks, > Conor. > > > > > + > > > > curr_cpuid = smp_processor_id(); > > > > store_cpu_topology(curr_cpuid); > > > > numa_store_cpu_info(curr_cpuid); > > > > -- > > > > 2.25.1 > > > > > > > > > > Otherwise, > > > > > > Reviewed-by: Andrew Jones Regards Ley Foon