From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 741BA346FB5 for ; Thu, 16 Jul 2026 06:43:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784184210; cv=none; b=WyYzSo2awnIjM47mlIZqLyHfBUyobj22vtjYUVPwpiVkewa9128HZSLAkxf86bkivfWPRNz/3ucL/midT7U1X4LfQxqOI8hd4OQKsx2oe+iI5dnCAwwchHSoAzARIIjSuBOgvvxHw8oq9jLCZ6GL+iBf5rpqx4v5OM45M98EHOQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784184210; c=relaxed/simple; bh=d6H/GK3G7mbF3k2iu0S4G2m9Rkbp1n+pobq5SOOaNfw=; h=From:To:Cc:Subject:In-Reply-To:Date:Message-ID:References; b=aw6HO7d1eAP9V6tGPiBZbOap9+oEcrqhHElT+TvBsoVA6FRAQxjoDuX6ihWHXCF6FydUmwF1jepoZQsMQv8Luh6X2JPkPWrpX3xFZYSaIMqcPwosuhO5CkpzrcOw8gfW5pODJN2H0ES4oamgqY3bX3TDmUa9bHKAdz296jkX7yg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=VgAt9OkL; arc=none smtp.client-ip=209.85.216.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="VgAt9OkL" Received: by mail-pj1-f54.google.com with SMTP id 98e67ed59e1d1-38e08baf860so3815879a91.2 for ; Wed, 15 Jul 2026 23:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784184209; x=1784789009; darn=vger.kernel.org; h=references:message-id:date:in-reply-to:subject:cc:to:from:from:to :cc:subject:date:message-id:reply-to:content-type; bh=DsLGcom3ZeTfINfwuqzujf0E8Uw6ZU39l4TQYXgHLvQ=; b=VgAt9OkLdTfqvGa8u4aTu1uAvyefC5cIOILGVUGhy3uWc7xuWEI1mQTAH7llVSP61h xT8JjKab176HDA7lLoAxYqo1SgsjE8YeioZ+GP6GlbafLQSPr6xYJhIk9v1VQxqiF4EC w3uOEtdzRPbsGt1v1IY7BmqB835oRwCaLzRSzzrABBTL2Gu1IQwOAYtCIlJPHdEE266y cFZkv9Pts+VCT+MRIaYX8cy0v5KZHth7yWl0OCttXUZvaPHgtpYf6yxrmrPaYhcUHXHX hKdBbuRc8gKUPlr1K42sGC+C4CR6KCw4qnXQJQ3D2yRpuKRMF0JRNKkP7lWFI2lxsemn QR8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784184209; x=1784789009; h=references:message-id:date:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=DsLGcom3ZeTfINfwuqzujf0E8Uw6ZU39l4TQYXgHLvQ=; b=SmeUi1liI3OuMTE/NZpNMdMQxQlrick1jHbtna7lCLhvwLII+RYxLfqpVRc3xVNLuh OldHKsfIImIXaey7rshZkZ+L99ijfdgmLkkp+Lz0LZ4r6rtDT9/xzJUEwLESKVQlqsQh yBrxQWEsyHyEw/pEiIJUJFWlD1RHw8fXfSG8DSUG2MfRrLd9wvXwmpXWDf2rRMkTmz5X vorq5Oc9f4kcUx/+Qcw4u/LO9L6laUIEle3mWVg/UmRSSMpL1uHcDfwqvheWVO9aNatG 1K1xOxbEOvH7vB1RBJJLcQRNd3PrVkhPGV3nTKv6YSPbFYDQOPIDLdrGLYjzlBpD9bW5 jinw== X-Forwarded-Encrypted: i=1; AHgh+RpaX6/R9rIT8Ar06vsLR6VYYElqbnTsK8Snxk49pxYbSsDgoxnC+bLhWqjbQY6YehPYbAIy0YROALHoRCA=@vger.kernel.org X-Gm-Message-State: AOJu0YxAAq8lExL4lgXZdUtWCQ0AOx+z6etY65VEnoQx1hVOMaQrnAOK BjMIlmgwdQa3ZLhVglSCN5qLgGrScE6dzjU81JuRcwX5+4j65Nl55moztLN+4w== X-Gm-Gg: AfdE7cnclUIF3vgOgsEzC0hsr0H11/59EefSIdACcOxXzTcLPnRYM/9G/XyQW4FMpFh v4WBCxZ3Dbd1yMoY7zNOKpjjWy+Yv0iReX8GzLz7ovmmAmjyKovZGuOK7Nm73pkvYAVHwjlJ3qQ UXBodtDVXQ18pgz8MLAc6itm6YFQ50rTea09dBlK4Sei6x1tI0EPeJfb+HtVzdDtQ8siY1LaOxB h53xEObVWpvMnMV7G4njn7O7dJnSik4RMoF8vz+nxF0kC+rIeVwzdreAJZMxbdxdH29puZstnjt FA35YmamxkGuPOw+OdoYYr852x7KAZAG0p33FwsKqwk597UffZAxsGgqVCiUCO3XFpjXVkAec+U Y3RYYKU5ahOC6M/Z5aCYYN5pPwFVocWc/hpPeQoko9GuIqX5DnNQsuSmsYWoXX7GaO4OGE1GCzT E1 X-Received: by 2002:a17:90b:2b43:b0:38d:eac8:2dbc with SMTP id 98e67ed59e1d1-38e29f6c683mr4912316a91.9.1784184208670; Wed, 15 Jul 2026 23:43:28 -0700 (PDT) Received: from pve-server ([49.205.216.49]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3140e6a626bsm8222656eec.19.2026.07.15.23.43.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jul 2026 23:43:26 -0700 (PDT) From: Ritesh Harjani (IBM) To: Srikar Dronamraju Cc: linuxppc-dev , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Naveen N Rao , skiboot@lists.ozlabs.org, arbab@linux.ibm.com, mahesh@linux.ibm.com, chleroy@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 3/3] powerpc/numa: Support coregroup on PowerNV In-Reply-To: Date: Thu, 16 Jul 2026 12:07:16 +0530 Message-ID: References: <20260605055242.1757485-5-srikar@linux.ibm.com> <20260605055242.1757485-8-srikar@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Srikar Dronamraju writes: > * Ritesh Harjani [2026-07-10 11:18:12]: > >> Srikar Dronamraju writes: >> >> > Coregroup support on powerpc has so far been limited to PowerVM LPARs. >> > However, PowerNV can also support coregroups when firmware exposes the >> > required coregroup information through the associativity hierarchy. >> > >> > Detect coregroup support by checking whether primary_domain_index is the >> > penultimate domain in the CPU node's ibm,associativity property. On >> > PowerNV, a non-penultimate primary_domain_index indicates that firmware >> > provides an additional level for coregroup information. >> > >> > This keeps the logic compatible with PowerVM systems, where >> > primary_domain_index is likewise not the penultimate associativity >> > domain. >> > >> > Signed-off-by: Srikar Dronamraju >> > --- >> > Changelog from v1: https://lkml.kernel.org/r/20260524010017.140408-1-srikar@linux.ibm.com >> > - Handle comments from Christophe Leroy; make code more flat >> > >> > arch/powerpc/mm/numa.c | 56 ++++++++++++++++++++++++++++++++++-------- >> > 1 file changed, 46 insertions(+), 10 deletions(-) >> > >> > diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c >> > index 9aa71eb7e96b..e97b624203ea 100644 >> > --- a/arch/powerpc/mm/numa.c >> > +++ b/arch/powerpc/mm/numa.c >> > @@ -889,12 +889,32 @@ static int __init numa_setup_drmem_lmb(struct drmem_lmb *lmb, >> > return 0; >> > } > > Hi Ritesh, > > Thanks for the review. > >> > >> > +/* >> > + * If hierarchy extends beyond primary_domain_index + 1, then next >> > + * level corresponds to coregroup. >> > + */ >> > +static int detect_and_enable_coregroup(const __be32 *associativity, int index) >> >> Do we care about it's return value? We are not reading that in the >> patch. > > Yes, We do care about the return value. If the index is set to -1, we don't > retry enabling the coregroup. > yes, my bad. Agreed it is being used. >> this function is mainly only needed in __init, can we mark it so. > > Yes, this will be done. > >> >> > +{ >> > + if (!associativity || index == -1) >> > + goto out; >> > + >> > + index = of_read_number(associativity, 1); >> > + >> > + if (index > primary_domain_index + 1) { >> > + coregroup_enabled = 1; >> > + return index; >> > + } >> > +out: >> > + coregroup_enabled = 0; >> > + return -1; >> > +} >> >> For PowerVM, we now have two places which will enable coregroup_enabled >> during mem_topology_setup(). Is there some way we can unify that? >> > > For PowerVM, we have two extra associativity properties > ibm,ibm,current-associativity-domains and ibm,max-associativity-domains. > On PowerNV, these two properties are not used/exported. > > All we depend is the layout of these properties to determine if coregroup is > enabled. If the layout tells us that there is place after > primary_domain_index for coregroup, we assume coregroup is enabled. > > So in this patch, we hook at the place we look at each of the CPU > associativity. This should work for both PowerVM and PowerNV. > > So, I can think of two options. > 1. Remove the previous logic of depending on PowerVM specific code. > 2. Allow the previous logic to be around. Since its not going to hurt > functionally or performance wise. > >> This also means we enable coregroup in case of PowerVM with SPLPAR when >> per-cpu VPHN associativity index > primary_domain_index+1. But this >> isn't reflected in your commit msg. The commit msg only says this >> affects PowerNV. > > I don't think, I said this affects PowerNV only. But I still don't think > the logic would change. The logic to enable coregroup remains the same. > Just that we may now be depending on the 1st CPU associativity instead of > the PowerVM specific properties. > So let's just add this info in the commit msg please. Because it was not clear otherwise. -ritesh