Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Message-ID: <03d36c51-d3f5-d77d-c304-d06e86f4f3e2@amd.com>
Date:   Wed, 20 Sep 2023 08:51:03 +0530
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.1
Subject: Re: [patch V4 24/41] x86/cpu: Provide cpu_init/parse_topology()
Content-Language: en-US
To:     Arjan van de Ven <arjan@linux.intel.com>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>, x86@kernel.org,
        Tom Lendacky <thomas.lendacky@amd.com>,
        Andrew Cooper <andrew.cooper3@citrix.com>,
        Huang Rui <ray.huang@amd.com>, Juergen Gross <jgross@suse.com>,
        Dimitri Sivanich <dimitri.sivanich@hpe.com>,
        Michael Kelley <mikelley@microsoft.com>,
        Wei Liu <wei.liu@kernel.org>, Pu Wen <puwen@hygon.cn>,
        Qiuxu Zhuo <qiuxu.zhuo@intel.com>,
        Sohil Mehta <sohil.mehta@intel.com>,
        Gautham Shenoy <gautham.shenoy@amd.com>,
        Peter Zijlstra <peterz@infradead.org>
References: <20230814085006.593997112@linutronix.de>
 <20230814085113.471353147@linutronix.de>
 <934072fe-eca2-44df-94e7-9fed1dc8b502@amd.com> <87r0nn8ots.ffs@tglx>
 <4a4d5a89-b024-ea49-8740-1f3aef412c15@amd.com>
 <abb65e60-4e8b-7036-4401-d21b273b6d67@linux.intel.com>
 <6f101718-7ee1-1c3d-3e0a-3aa708928ecd@amd.com>
 <20230915115428.GD6721@noisy.programming.kicks-ass.net>
 <9ffe31b0-a6ff-991d-85ad-97306abfc684@linux.intel.com>
 <106c0cef-2cde-7330-7a18-31db92c5b04a@amd.com>
 <13c2f8b6-f0ca-8c68-603a-a0efdc80164f@linux.intel.com>
From:   K Prateek Nayak <kprateek.nayak@amd.com>
In-Reply-To: <13c2f8b6-f0ca-8c68-603a-a0efdc80164f@linux.intel.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?d3R0NTNKa2ZTL1ZadzM5RzVNVXJ1Nks0clRwUDJ6NXQxRmdINlJLSHdUblZr?=
 =?utf-8?B?WGZiZzFUc3cxM3FoWEpiTXVVeEJqeFZEQWxMTmRnaFFOeE1Ydnc5cmJ3bS9U?=
 =?utf-8?B?NjFZbEMrMFQrdllPeWZmWnY5TktGZ0YvMEJvSm5RcU5ncjVYSHp0M2I2dGVS?=
 =?utf-8?B?NlgxTlFOZU13NXloNUtoS3hwOXYxZmppZ0cwM3k5RVNodG9EZDBGSU85SWpD?=
 =?utf-8?B?SEVWUGtGSDY5ZDZZTVVyZ1JKR3dLYkZoYzNIU1dFOFIzSmNWdVNBVzRuQXha?=
 =?utf-8?B?MmZERThhckF6UWE3aC93cnRzV2dNbXpEVGYxakVHdDZMVUVrU2k1SGpEU3JX?=
 =?utf-8?B?UW9tdzFXdmFIck5XNG5HZXJ6bldRWldYb09IL0xmUXI2aFRqRTZERGNULytv?=
 =?utf-8?B?US9Ba1ROMlJHb21FdWVOckdNTHVPSndSekszN0hnZVZJQmRjL3dUZTdWYVFK?=
 =?utf-8?B?SkpWdHJhMUg2NDdvR0owOUJmLzJ0SUtCTTNCNDRnNU5JU0N1eGd3ckF2TjZo?=
 =?utf-8?B?TUdubzNVSmc3K3JsM3ozRGxxa1hEL3VJN05GWXNLaHFYVTNaNTlFSTZHL3FZ?=
 =?utf-8?B?R21GZC8xYnZaUEpkaEpIWlR5Y3FuZjZHYWs2UTFJZlFIdWg1dVJXZ0lZQ0po?=
 =?utf-8?B?a1NDV0JJOXdDTEpUTURVMXI3Tm9PSG95YnYvQ05yNW52bEpYNG5WUEtYeU1t?=
 =?utf-8?B?Q0RBOUcwUlpzSTJXa25OYmk2VFZGQ0VmVVp3M0ZHYVhpZzJob2t3V2w3U3NK?=
 =?utf-8?B?R3J2RHVqUUZTU2FveTJaeEx2MU5zYUVydjZudU9vN1hHNm5wWlFTaDdBTzFi?=
 =?utf-8?B?VUxBUGFJVkdYWVpBbTdmUzBZUjdDeEEzM1BYcTl4SVp2eGdCQTIwWTEyYjFB?=
 =?utf-8?B?bGp4KzFSdnd5aElYaEpoNXhESmk5S2gzcnRhcFpoalBITng2SzZkVm81SEhR?=
 =?utf-8?B?MVRqTjd1MGZGSktkL3RQdXZGYVBmak9jZVh2bWY3bjZ3SmZZUDZ4amlranJX?=
 =?utf-8?B?dmRyNW5QRkJFOXUyODNOMVdMeWhhTHpRdjArNzd0d0lxQTEwVFNKK1hZMGRO?=
 =?utf-8?B?MDZROC9YYzdXbUZad1gxWE9qaVVMbmIwZS9wcitPTWpST2tpSTc0ZHY2ZXdt?=
 =?utf-8?B?OEhnT0g2RDl0OHFiVUxJNG1MSlhaV0k4OWVkTGt5VTVuVmw0SFNmbDZiYStw?=
 =?utf-8?B?ajFiV3lqVFp3WW4vZ0RnQXQzbEwvNjNwc0R3eFNsVlhWby9WOEwvbnBWa2Iz?=
 =?utf-8?B?ZHp3SU5TZmtlMzJGYjBiNllCd05Ld0hPTXBIVjVqRFd4QTU5R05oU3ZIYTk0?=
 =?utf-8?B?Ymp1dWcvUTgvUDdKMEJPUFQrSTF5bHFVM29DcldmUlhOc2dPb2I3OWpoZWJV?=
 =?utf-8?B?UE82UW9oL1JkaEt1em51dlVOTklOVldzMHVRekhFUi9uMFExeDJUanUweU5h?=
 =?utf-8?B?aEF1UWNVZUVMdzVPUVBHTStTQWo3ZEdla01UazNzM2lUaGI4K0hYQzZOYXQr?=
 =?utf-8?B?OWVvalZjUTNVUkhaZVF1dGx5TlNEVDB6TlN3d082Nmx4VmdwNXFpT2FRUTJw?=
 =?utf-8?B?QWIvOEVZZnQxUVVreG9PckRzeVF1YU5mTGVpOWFOZnB0Sk9vQ3RVekgzdkxa?=
 =?utf-8?B?cjFEMlQvR3VNNEZqTFhjTStOYjNVNS9YWno2Ym5vNTVGNXZUWjR2MVVrU0R5?=
 =?utf-8?B?aVp1a2NRZ0s2ZVdISzRhNTVXZUZ6VkJibEo4YTZNRThyWHRHOEkzaklRbFRk?=
 =?utf-8?B?SG1vWGhYT3g2WkJuZkJxTW96RUQ2aDYrbzg2QVJxOThSUzJzdTNQT01KUU92?=
 =?utf-8?B?bkFFelJLbFRYOWI5ZXE5bk1mSUJqVmp4RkFuQmJVZTR5RTRUMUhzazU5bWk4?=
 =?utf-8?B?ZmVwcVU3ZDZxUWRzYnhPMk1qL1hraVNzSjRIVllWWkY4RGZybGZuRHFueS83?=
 =?utf-8?B?Z3FnT3gzeEhGcXhEOGtXaDY1a1IvTkdYc2NoOGREcHpJTXZmUmZSWHByRnBV?=
 =?utf-8?B?SlBGcnpHaXY5akxSUENLanhaU1R3OWcyVVkrVnZabmdQL0VWU1A3MW5NR09M?=
 =?utf-8?B?a3JUbHFCc2h6UWd0NWRWOCtpd1ZTVlkwbzFGSWlUMGR1dktVWVFJVEdsYzJs?=
 =?utf-8?Q?92Sv5vU7cSCh3XyS1nbln449N?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: df53a27a-4222-4a56-b995-08dbb988a69f
X-MS-Exchange-CrossTenant-AuthSource: MW2PR12MB2379.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2023 03:21:17.5679
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: hcxTq9uO2AgdtFfAKa3Db2BJap7qSsQrpqOOjjYZQivyfTcdLo9svK94Q46/dCEL6jCf6eSrbUNY7kbfqBezPw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4886
X-Spam-Status: No, score=-2.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Tue, 19 Sep 2023 20:21:37 -0700 (PDT)

Hello Arjan,

On 9/19/2023 7:14 PM, Arjan van de Ven wrote:
> 
>>>>> specifically "... combining up to four Intel 7-built tiles on a single
>>>>> package, connected using Intel EMIB ...". Perhaps the one from Qiuxu
>>>>> Zhuo's report does not contain multiple tiles.
>>>>
>>>> I think what Arjan was saying that despite them being build using
>>>> multipe physical tiles, they describe themselves, in the topology leave,
>>>> as being a single tile.
>>>
>>> and more than that -- from a software perspective, they truely act as if they are 1 tile
>>
>> If possible, can you please elaborate on the "software perspective". Say
>> CPUID leaf 0x1f reports multiple tile, would the data access latency or
>> cache to cache latency see a noticeable difference?
> 
> no. (not on SPR unless you turn on SNC, which is a whole different world)
> 
>>
>> I would like to understand what the characteristics of a "Tile" are and
>> whether they are similar to AMD's CCX instances discoverable by AMD's
>> extended CPUID leaf 0x80000026. That way, in future, when the generic
>> topology is used by other subsystems, the data from "TOPO_TILE_DOMAIN"
>> can be used generically for both Intel and AMD.
> 
> SPR for all intents and purposes for software does not have tiles. So please
> lets not design for that ;-)
> 
> The reality is that we really should not hardcode topology things to cache things.
> Sure today tile is an L3 boundary for AMD, and on all no-tile systems by construction
> of the topology tree.
> But maybe some smart person in AMD decides
> that for a next generation, it's faster to split the L3 in half -- or to make that
> extra HBM-like cache span 2 tiles or .. or ..
> 
> CPUID enumerates cache domains pretty much separate and that;s a good thing.
> We absolutely need a "cache view" of the system, but that is a mapping to topology,
> not hardcoded in topology (so one level of indirection + of course cached/computed
> bitmaps etc for cheap access)
> 
> 
Makes sense! I think that is the reason we have Cache Identifiers in the
first place. I'm satisfied with the explanation from Thomas
(https://lore.kernel.org/lkml/87y1h2wpfw.ffs@tglx/) as long as their use
in the future, in generic code, does not assume any characteristics that
is not generic to the whole of x86 :)

--
Thanks and Regards,
Prateek