linux-kernel - Re: [patch V4 24/41] x86/cpu: Provide cpu_init/parse

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <13c2f8b6-f0ca-8c68-603a-a0efdc80164f@linux.intel.com>
Date:   Tue, 19 Sep 2023 06:44:22 -0700
From:   Arjan van de Ven <arjan@...ux.intel.com>
To:     K Prateek Nayak <kprateek.nayak@....com>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        Tom Lendacky <thomas.lendacky@....com>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        Huang Rui <ray.huang@....com>, Juergen Gross <jgross@...e.com>,
        Dimitri Sivanich <dimitri.sivanich@....com>,
        Michael Kelley <mikelley@...rosoft.com>,
        Wei Liu <wei.liu@...nel.org>, Pu Wen <puwen@...on.cn>,
        Qiuxu Zhuo <qiuxu.zhuo@...el.com>,
        Sohil Mehta <sohil.mehta@...el.com>,
        Gautham Shenoy <gautham.shenoy@....com>
Subject: Re: [patch V4 24/41] x86/cpu: Provide cpu_init/parse_topology()


>>>> 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)