From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AE983313555 for ; Fri, 20 Feb 2026 09:54:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771581258; cv=none; b=SAEYHWcicEtxqu9OsPuuJfA5fNP2ttyM/eqzYmH2RFy+OSV/m/EIC1gHNcSGX/dS7oK0H4kwjavRz6KmJJMBC24j+dERr00xzqEA6ElhV8wHwwvgFt/pIkRY602XV5gFodvQSH7QtI5699Q1h5/F3tiKeI57l1bskTrhV1XMpFY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771581258; c=relaxed/simple; bh=d9D4RE1dlsCdr3pWnrhRZADpvOK0ZLQcuO0RbsrbGA8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fA1b/reUwYQt6fVJjFk/nsk71+h+fOr2hJnhxSZv4ZxiqXgeDganMeRyu1cr63l7iTJaYk3x7bxkWstOYLrZsK6l5v9LSZs5W1voPxHn4jdXz/OC2w39sXPQZmFx8FmM6af5Ab7QVkyHZhm6MeNL8g5cYNsydMEzwuiIHFC2RGs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=pgYbcS0n; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="pgYbcS0n" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Ok3p2i2I3uIk6Sjdt/7VexZQeqoVjSoykX547mQid1c=; b=pgYbcS0n5UfDofBiMd/FH0xmCY ab5yNtqQLsxdi7NgtVI9uxAT8jH3IdWzyRD+pybiefa+BOaUXXzVACUM9UGyCsb3pWMLjPVuc89gQ IG1tV/AlFhXkd/WFqYoVaJ3sHGAOIWtHNusvVmsCx2i0gz4wMie+3Tx/pg/39eqZWxa6LA7lSxWoV EDP9e6MHoRYYq4ufNosWDe4RlOWROMPoEnTPOQ3APB220r1gFWmKluINugQ75MbQrqGL/z5IIwPdH nWrV+a2VV/y1QPiH5A3ouUEtkNN4m8XJZuvZc+2FEzqfRuxSNbvqesWYND8aXj7KNzA6Yj5M7Yfm8 WiPwbZCA==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vtNCT-00000002QJk-04cU; Fri, 20 Feb 2026 09:53:33 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 715FB301BD5; Fri, 20 Feb 2026 10:53:27 +0100 (CET) Date: Fri, 20 Feb 2026 10:53:27 +0100 From: Peter Zijlstra To: Madadi Vineeth Reddy Cc: Tim Chen , Ingo Molnar , K Prateek Nayak , "Gautham R . Shenoy" , Vincent Guittot , Chen Yu , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Hillf Danton , Shrikanth Hegde , Jianyong Wu , Yangyu Chen , Tingyin Duan , Vern Hao , Vern Hao , Len Brown , Aubrey Li , Zhao Liu , Chen Yu , Adam Li , Aaron Lu , Tim Chen , Josh Don , Gavin Guo , Qais Yousef , Libo Chen , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 15/21] sched/cache: Disable cache aware scheduling for processes with high thread counts Message-ID: <20260220095327.GG2995752@noisy.programming.kicks-ass.net> References: <20260219165507.GN1395266@noisy.programming.kicks-ass.net> <44a3bf9b-b728-4c33-8972-dbd1a3a873e2@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44a3bf9b-b728-4c33-8972-dbd1a3a873e2@linux.ibm.com> On Fri, Feb 20, 2026 at 12:10:21PM +0530, Madadi Vineeth Reddy wrote: > Hi Peter, > > On 19/02/26 22:25, Peter Zijlstra wrote: > > On Wed, Feb 18, 2026 at 11:24:05PM +0530, Madadi Vineeth Reddy wrote: > >> Is there a way to make this useful for architectures with small LLC > >> sizes? One possible approach we were exploring is to have LLC at a > >> hemisphere level that comprise multiple SMT4 cores. > > > > Is this hemisphere an actual physical cache level, or would that be > > artificial? > > It's artificial. There is no cache being shared at this level but this is > still the level where some amount of cache-snooping takes place and it is > relatively faster to access the data from the caches of the cores > within this domain. > > We verified with this producer consumer workload where the producer > and consumer threads placed in the same hemisphere showed measurably > better latency compared to cross-hemisphere placement. So I just read the Power10 Wikipedia entry; that seems to suggest there actually is a significant L3 at the hemisphere level. That thing states that Power10 has: - 16 cores in two hemispheres of 8 cores each. - each core has 2M L2 cache - each hemi has 64M of L3 cache Then there appears to be a 'funny' in that there's always one 'dead' core, so you end up with 8+7, and the small hemi looses an 8M L3 slice due to that. Now, I'm just reading a Wiki pages written by a random person on the interweb, so perhaps this is wrong (in which case I would suggest you get someone from IBM to go and edit that page and provide references), or there has been a miscommunication somewhere else, and perhaps there really is L3 at the hemi level, and arch/powerpc/ 'forgot' to expose that :-)