Red Hat Bugzilla – Bug 472824
sysfs doesn't export CPU cache info for some CPUs
Last modified: 2014-06-02 09:07:12 EDT
Description of problem:
Since the format of /proc/cpuinfo varies greatly between architectures, /sys/devices/system/cpu/cpu0/cache is the preferred method for userspace applications to get information about the CPU cache. On (at least my) netburst-based Xeon system, this sysfs directory does not exist, making it more difficult for applications to optimize their data structures for the CPU.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install RHEL 5.3 Server beta on a system with dual 2.8 GHz Prescott Xeons.
2. ls /sys/devices/system/cpu/cpu0/cache
ls: /sys/devices/system/cpu/cpu0/cache: No such file or directory
index0 index1 index2
Might be due to the screwy clflush/cache_alignment disagreement on some netburst processors, such as this one. I do have Adjacent Cache Line prefetch enabled in the BIOS. Since the system is dual-socket/single-core/hyperthreaded, I get four entries like this in /proc/cpuinfo:
processor : 3
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 2.80GHz
stepping : 3
cpu MHz : 2793.262
cache size : 2048 KB
physical id : 3
siblings : 2
core id : 0
cpu cores : 1
apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 3
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr
bogomips : 5586.29
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
Just saw this again inside a KVM guest running on a Core 2 Duo E6850. Baremetal sees the sysfs file, both in F10 and RHEL 5.3 beta.
Investigation into brc#511278
The /sys/devices/system/cpu/cpuX/cache/ sysfs directories are created in arch/i386/kernel/cpu/intel_cacheinfo.c (for both i386 and x86_64).
The addition of the cache information for this processor is either failing because (num_cache_leaves == 0), or failing somewhere in cache_add_dev(), since it
can be assumed that once register_hotcpu_notifier() is called, cacheinfo_cpu_callback() is correctly called as appropriate.
The case that (num_cache_leaves == 0) is only possible if the CPUID instruction is failing on the processor. This is the most likely problem, since there are
other reports of odd behaviour of the CPUID instruction on Xeon processors. This can be checked for by using the cpuid program in userspace, and noting its output.
No other functions or esoteric instructions are called to initialise num_cache_leaves:
/* Do cpuid(4) loop to find out num_cache_leaves */
cpuid_count(4, i, &eax, &ebx, &ecx, &edx);
cache_eax.full = eax;
} while (cache_eax.split.type != CACHE_TYPE_NULL);
It is possible that adding the cache information is failing in cache_add_dev(). The only processor-dependent failure point here is the call to cpuid4_cache_sysfs_init(),
which results in a call to detect_cache_attributes(). Here, either the set_cpus_allowed() call is failing (unlikely), or cpuid4_cache_lookup() is failing. This brings
us round to the same conclusion: that the CPUID instruction, as issued by Linux, doesn't work on this particular model of processor.
Digging into the exact CPUID call in cpuid_count() in include/asm-i386/processor.h, we have the following assembly:
: "=a" (*eax),
: "0" (op), "c" (count));
The calls in intel_cacheinfo.c are the only ones in the kernel which set ecx to a non-zero value before issuing the CPUID instruction. Perhaps this is what's causing
the problem? The information displayed in /proc/cpuinfo is returned by a call to CPUID with ecx=0, and that appears to work fine.
More analysis would be possible if the cpuid program could be run on the system and its output provided.
There is no indication that the problem's caused by the mismatch between clflush size and cache alignment.
This bug/component is not included in scope for RHEL-5.11.0 which is the last RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX (at the end of RHEL5.11 development phase (Apr 22, 2014)). Please contact your account manager or support representative in case you need to escalate this bug.
Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in RHEL5 stream. If the issue is critical for your business, please provide additional business justification through the appropriate support channels (https://access.redhat.com/site/support).