Open jbd opened 7 months ago
Please find attached the output of cache-info with and without the nosmt option, when cpuinfo is built with debug log level.
Looking at the x86 logic (I'm horribly unfamiliar with it, so bear with me here :)), it looks like we'd only accidentally generate N caches if we assigned them each different L1I IDs. Digging through the code paths here, I don't see anywhere we would accidentally mark the same ID as different IDs, so that leads me to believe that our l1i_id calculation fails somehow.
# How we calculate the apic_bits for each cache in `cpuinfo_x86_decode_cache_properties`.
const uint32_t cores = 1 + ((regs.eax >> 14) & UINT32_C(0x00000FFF));
const uint32_t apic_bits = bit_length(cores);
...
# How we later mask to acquire the L1I ID.
const uint32_t apic_id = linux_processors[i].apic_id;
const uint32_t l1i_id = apic_id & ~bit_mask(x86_processor.cache.l1i.apic_bits);
I'd hazard a guess that this means either:
apic_id
is wrong for all processors with 'nosmt' enabled?apic_bits
is wrong for all caches with 'nosmt' enabled?
Hello,
I'm using the main branch of today (https://github.com/pytorch/cpuinfo/commit/3c8b1533ac03dd6531ab6e7b9245d488f13a82a5) and I've got incorrect output in cache-info on a machine booted with the "nosmt" kernel command line parameter:
WITH the "nosmt" parameter (note the weird "shared by XX processors" at the end of each line):
WITHOUT the "nosmt" parameter:
lscpu output WITH the "nosmt" parameter:
lscpu output WITHOUT the "nosmt" parameter:
The difference is are on the On-line/Off-line CPU(s) lists.
It caught me by surprise with a SIGFPE when using the NNPACK project (https://github.com/Maratyszcza/NNPACK/issues/218).
Thank you for your help.