Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp913708iog; Wed, 29 Jun 2022 12:51:35 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sn4bC9YAtmHD7zFF0/89/M56EkzFUCh+TAYQl1y0WRROovEnGLY//r+z3subLsHJoPIl7s X-Received: by 2002:a17:90b:3d0f:b0:1ed:3b8c:7cb1 with SMTP id pt15-20020a17090b3d0f00b001ed3b8c7cb1mr5748828pjb.44.1656532295126; Wed, 29 Jun 2022 12:51:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656532295; cv=none; d=google.com; s=arc-20160816; b=XWrc4ZREuMMH/d0nUypY33pNWc7GpQqVVa4qbkeBLKohIhWqSUdnjy8Am+CAtVskHR KPN6/sCF1OUJD2yb5d1g+Yq626mEJGuJ1TL3Bs+v7DxLeDKJumut5iQSsu92mzG/y5HI baB1l4i+aYXj+IuS0M/DhhxxG9Jwkz67VgsVi4hy3LMsVXr9nIVXO2RG3sI+zMqr+w0D QP5lfFgz4ovU1Av7kFw0tj9W6q5Y3BNKWCcHIHHSAIY9Dn+3jY84WoIx58vi2gC9zfe/ 85e8+9uNmHL7TQYGS5rIh1I1DmWpLwog54IKD/4jvgiX+pUkS15Rf+sAyGhDTc7YMqvG ctRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=0Dp1/STl1qQZB2ibnEUsry6b51rVcQI69e8TQz/I+6o=; b=CSXS9wsjpPFbKcsezvmnlbYCrbQicJcZnyN8hX0Y5i1A+/kY3WCd4pyBD1NuXlhZp8 9uD5/q/+9WJrj/ZRLq/NonirJt2XIfWgs/nqR950CrgeOA21CDJoo/Z0UIwJcXbXwaai 7H+VSUkqJb0ibIOo8o1xCQg++PQPZSksFjA9cmrWXYbkwHHGi0BFSRxUwN4hGSY50bjg Xmoc+wAe0+UdnldsosINQTM1sk9hLe7kg7o3BMKIFj59JYoRl106NSzkcz5lAtIMWP6+ yeNo1nl90QTw0xSqla4G3JkFZhhlcCemFJLrK6H1SLtkK6Yezm4FQoJYfhR1Z/+LdaHf SBrQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i7-20020a170902c94700b001678898e70bsi27260850pla.223.2022.06.29.12.51.23; Wed, 29 Jun 2022 12:51:35 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230399AbiF2TOH (ORCPT + 99 others); Wed, 29 Jun 2022 15:14:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229778AbiF2TOG (ORCPT ); Wed, 29 Jun 2022 15:14:06 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 52E1533349 for ; Wed, 29 Jun 2022 12:14:05 -0700 (PDT) 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 151EA1480; Wed, 29 Jun 2022 12:14:05 -0700 (PDT) Received: from bogus (unknown [10.57.39.193]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A06C63F792; Wed, 29 Jun 2022 12:14:01 -0700 (PDT) Date: Wed, 29 Jun 2022 20:12:50 +0100 From: Sudeep Holla To: Conor.Dooley@microchip.com Cc: linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org, atishp@atishpatra.org, atishp@rivosinc.com, Sudeep Holla , vincent.guittot@linaro.org, dietmar.eggemann@arm.com, wangqing@vivo.com, robh+dt@kernel.org, rafael@kernel.org, ionela.voinescu@arm.com, pierre.gondois@arm.com, linux-arm-kernel@lists.infradead.org, linux-riscv@lists.infradead.org, gshan@redhat.com, Valentina.FernandezAlanis@microchip.com Subject: Re: [PATCH v5 09/19] arch_topology: Use the last level cache information from the cacheinfo Message-ID: <20220629191250.mg3dybgl6hnlnqee@bogus> References: <20220627165047.336669-1-sudeep.holla@arm.com> <20220627165047.336669-10-sudeep.holla@arm.com> <3656a067-cc3f-fd5b-e339-5925a856cce1@microchip.com> <20220629184708.x5exgjoy4sblyqml@bogus> <88ef07ea-fbde-b997-6c0c-99f5fb7be201@microchip.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <88ef07ea-fbde-b997-6c0c-99f5fb7be201@microchip.com> X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE 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 On Wed, Jun 29, 2022 at 06:56:29PM +0000, Conor.Dooley@microchip.com wrote: > On 29/06/2022 19:47, Sudeep Holla wrote: > > On Wed, Jun 29, 2022 at 06:18:25PM +0000, Conor.Dooley@microchip.com wrote: > >> On 29/06/2022 18:49, Conor.Dooley@microchip.com wrote: > >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > >>> > >>> On 27/06/2022 17:50, Sudeep Holla wrote: > >>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > >>>> > >>>> The cacheinfo is now initialised early along with the CPU topology > >>>> initialisation. Instead of relying on the LLC ID information parsed > >>>> separately only with ACPI PPTT elsewhere, migrate to use the similar > >>>> information from the cacheinfo. > >>>> > >>>> This is generic for both DT and ACPI systems. The ACPI LLC ID information > >>>> parsed separately can now be removed from arch specific code. > >>> > >>> Hey Sudeep, > >>> I bisected broken boot on PolarFire SoC to this patch in next-20220629 :/ > >>> I suspect the issue is a missing "next-level-cache" in the the dt: > >>> arch/riscv/boot/dts/microchip/mpfs.dtsi > > > > Good that I included this in -next, I had not received any feedback from > > RISC-V even after 5 iterations. > > I'll be honest, I saw the titles and CC list and made some incorrect > assumptions as to whether looking at it was worthwhile! I am not at > this all too long and what is/isn't important to look at often is not > obvious to me. No worries, that's why I thought better to include in -next to get some attention and I did get it this time, hurray! ???? > But hey, our CI boots -next every day for a reason ;) > Good to know and that is really great. Anyways let me know if the diff I sent helps. I strongly suspect that is the reason, but I may be wrong. > > I also see this DTS is very odd. It also > > states CPU0 doesn't have L1-D$ while the other 4 CPUs have L1-D$. Is that > > a mistake or is it the reality ? > > AFAIK, reality. It's the same for the SiFive fu540 (with which this shares > a core complex. See page 12: > https://static.dev.sifive.com/FU540-C000-v1.0.pdf > > > Another breakage in userspace cacheinfo > > sysfs entry of cpu0 has both I$ and D$. > > Could you clarify what this means please? Ignore me if the cpu0 really doesn't have L1-D$. However the userspace sysfs cacheinfo is incomplete without linking L2, so it can be considered as wrong info presented to the user. Check /sys/devices/system/cpu/cpu/cache/index/*. L2 won't be present there as the link with next-level-cache is missing. So userspace can interpret this as absence of L2. -- Regards, Sudeep