Re: [PATCH RFC] x86/cacheinfo: Remove get_cache_id() due to ID collisions

[Ricardo Neri]

On Mon, Nov 09, 2026 at 05:55:37PM +0100, Javid Rzayev wrote:
> On Thu, Mar 19, 2026 at 05:38:00AM -0700, Ricardo Neri wrote:
> > calc_cache_topo_id() and get_cache_id() both compute cache IDs used to
> > determine which CPUs share a cache. Intel processors use
> > calc_cache_topo_id(), while Hygon and recent AMD processors use
> > get_cache_id(). Intel processors use get_cache_id() as well, but only to
> > populate /sys/devices/system/cpu/cpuN/cache/index*/id.
> 
> Hi Ricardo,
> 
> On Intel hybrid parts the bad IDs do not stay confined to
> cache/index*/id: after CPU hotplug they leak into shared_cpu_list.
> 
> I hit the collision on Arrow Lake-S (Core Ultra 7 265, 8P+12E, no
> SMT). Even without SMT, CPUID leaf 4 on the P-cores reports 2 threads
> sharing L1, so get_cache_id() shifts P-core APIC IDs by 1 and E-core
> APIC IDs by 0:
> 
>   CPU  type  APICID  L1 id (unpatched)
>    4   P     0x30    0x18
>    8   E     0x18    0x18   <- collides with CPU4
>    5   P     0x38    0x1c
>   10   E     0x1c    0x1c   <- collides with CPU5
> 
> When a CPU goes offline, cache_shared_cpu_map_remove() clears
> cpu_map_populated. When it comes back online, the LLC is still valid,
> so x86 populate_cache_leaves() is skipped and the generic
> cache_shared_cpu_map_setup() rebuilds the maps by comparing ci->id.
> 
> On v7.4-rc2 (unpatched), right after boot L1 shared_cpu_list is
> correct (cpu4: "4", cpu8: "8") and only the IDs collide. After
> offlining and onlining cpu8 it becomes "4,8" for both CPUs, i.e. a
> P-core and an E-core appear to share L1. On a distro 6.12 kernel,
> after several suspend/resume cycles both pairs (4,8 and 5,10) were
> wrong.
> 
> With this patch applied on v7.4-rc2, L1 IDs equal the APIC IDs and
> are unique. Offlining/onlining cpu8 and cpu10 leaves all
> shared_cpu_lists intact. L2 IDs change (e.g. 0x3 -> 0x18 for the
> cluster of CPUs 8-11) but the shared_cpu_lists are unchanged.
> 
> It may be worth mentioning the hotplug effect in the changelog. Do you
> plan to post a non-RFC version to the x86 maintainers?
> 
> Tested-by: Javid Rzayev <rz.cavid@xxxxxxxxx>

Hi Javid,

Many thanks for testing this patch and making the observation about
the CPU hotplug effect.

I do plan to post a non-RFC version of the patch and I will be sure
to mention your observation along with your Tested-by tag.

Best,
Ricardo