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 X-Spam-Level: X-Spam-Status: No, score=-11.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 76350C433DF for ; Mon, 20 Jul 2020 05:50:36 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CEBD2207DF for ; Mon, 20 Jul 2020 05:50:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CEBD2207DF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.vnet.ibm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4B99n52nG4zDqP6 for ; Mon, 20 Jul 2020 15:50:33 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=linux.vnet.ibm.com (client-ip=148.163.156.1; helo=mx0a-001b2d01.pphosted.com; envelope-from=srikar@linux.vnet.ibm.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=fail (p=none dis=none) header.from=linux.vnet.ibm.com Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4B99kl45JyzDqLg for ; Mon, 20 Jul 2020 15:48:31 +1000 (AEST) Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06K5X5x0114833; Mon, 20 Jul 2020 01:48:27 -0400 Received: from ppma03ams.nl.ibm.com (62.31.33a9.ip4.static.sl-reverse.com [169.51.49.98]) by mx0a-001b2d01.pphosted.com with ESMTP id 32bwmkfr82-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Jul 2020 01:48:26 -0400 Received: from pps.filterd (ppma03ams.nl.ibm.com [127.0.0.1]) by ppma03ams.nl.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 06K5jDM5023665; Mon, 20 Jul 2020 05:48:24 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma03ams.nl.ibm.com with ESMTP id 32brq7j7d3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Jul 2020 05:48:24 +0000 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 06K5mJpr25624998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 20 Jul 2020 05:48:19 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7BA0CAE05A; Mon, 20 Jul 2020 05:48:19 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 99070AE057; Mon, 20 Jul 2020 05:48:17 +0000 (GMT) Received: from linux.vnet.ibm.com (unknown [9.126.150.29]) by d06av26.portsmouth.uk.ibm.com (Postfix) with SMTP; Mon, 20 Jul 2020 05:48:17 +0000 (GMT) Date: Mon, 20 Jul 2020 11:18:16 +0530 From: Srikar Dronamraju To: Gautham R Shenoy Subject: Re: [PATCH 10/11] powerpc/smp: Implement cpu_to_coregroup_id Message-ID: <20200720054816.GA21103@linux.vnet.ibm.com> References: <20200714043624.5648-1-srikar@linux.vnet.ibm.com> <20200714043624.5648-11-srikar@linux.vnet.ibm.com> <20200717082652.GF32531@in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20200717082652.GF32531@in.ibm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-20_01:2020-07-17, 2020-07-20 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 priorityscore=1501 phishscore=0 clxscore=1015 mlxscore=0 bulkscore=0 lowpriorityscore=0 suspectscore=0 spamscore=0 impostorscore=0 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007200040 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Srikar Dronamraju Cc: Nathan Lynch , Oliver OHalloran , Michael Neuling , Michael Ellerman , Anton Blanchard , linuxppc-dev , Nick Piggin Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" * Gautham R Shenoy [2020-07-17 13:56:53]: > On Tue, Jul 14, 2020 at 10:06:23AM +0530, Srikar Dronamraju wrote: > > Lookup the coregroup id from the associativity array. > > > > If unable to detect the coregroup id, fallback on the core id. > > This way, ensure sched_domain degenerates and an extra sched domain is > > not created. > > > > Ideally this function should have been implemented in > > arch/powerpc/kernel/smp.c. However if its implemented in mm/numa.c, we > > don't need to find the primary domain again. > > > > If the device-tree mentions more than one coregroup, then kernel > > implements only the last or the smallest coregroup, which currently > > corresponds to the penultimate domain in the device-tree. > > > > Cc: linuxppc-dev > > Cc: Michael Ellerman > > Cc: Nick Piggin > > Cc: Oliver OHalloran > > Cc: Nathan Lynch > > Cc: Michael Neuling > > Cc: Anton Blanchard > > Cc: Gautham R Shenoy > > Cc: Vaidyanathan Srinivasan > > Signed-off-by: Srikar Dronamraju > > --- > > arch/powerpc/mm/numa.c | 17 +++++++++++++++++ > > 1 file changed, 17 insertions(+) > > > > diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c > > index d9ab9da85eab..4e85564ef62a 100644 > > --- a/arch/powerpc/mm/numa.c > > +++ b/arch/powerpc/mm/numa.c > > @@ -1697,6 +1697,23 @@ static const struct proc_ops topology_proc_ops = { > > > > int cpu_to_coregroup_id(int cpu) > > { > > + __be32 associativity[VPHN_ASSOC_BUFSIZE] = {0}; > > + int index; > > + > > It would be good to have an assert here to ensure that we are calling > this function only when coregroups are enabled. > > Else, we may end up returning the penultimate index which maps to the > chip-id. > We have a check below exactly for the same reason. Please look below. > > > > + if (cpu < 0 || cpu > nr_cpu_ids) > > + return -1; > > + > > + if (!firmware_has_feature(FW_FEATURE_VPHN)) > > + goto out; > > + > > + if (vphn_get_associativity(cpu, associativity)) > > + goto out; > > + > > + index = of_read_number(associativity, 1); > > + if ((index > min_common_depth + 1) && coregroup_enabled) > > + return of_read_number(&associativity[index - 1], 1); See ^above. index would be the all the domains in the associativity array, min_common_depth would be where the primary domain or the chip-id is defined. So we are reading the penultimate domain if and only if the min_common_depth isn't the primary domain aka chip-id. What other check /assertions can we add? > > + > > +out: > > return cpu_to_core_id(cpu); > > } > > > > -- > > 2.17.1 > > -- Thanks and Regards Srikar Dronamraju