Bug 1253842
Summary: | [aarch64] lscpu shows 4 sockets on a single socket SoC | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Richard W.M. Jones <rjones> | ||||||||||
Component: | kernel | Assignee: | Jon Masters <jcm> | ||||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||
Priority: | unspecified | ||||||||||||
Version: | rawhide | CC: | ddutile, gansalmon, itamar, jeremy.linton, jonathan, kernel-maint, kzak, labbott, madhu.chinakonda, mchehab, rjones | ||||||||||
Target Milestone: | --- | Keywords: | Tracking | ||||||||||
Target Release: | --- | ||||||||||||
Hardware: | aarch64 | ||||||||||||
OS: | Unspecified | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2019-03-05 14:01:52 UTC | Type: | Bug | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Bug Depends On: | |||||||||||||
Bug Blocks: | 245418 | ||||||||||||
Attachments: |
|
Description
Richard W.M. Jones
2015-08-14 21:22:25 UTC
With kernel 4.2.0-0.rc2.git0.1.fc23.aarch64 the output is the same: # lscpu Architecture: aarch64 Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 1 Core(s) per socket: 2 Socket(s): 4 I'm attaching the dmesg output in case that is useful. Created attachment 1063171 [details]
dmesg
Currently, the report by lspu, which is derived from the cpu topology under sysfs, is comprised from two possible sources: -- DT entries, which are often not filled out; -- but more of it is getting filled out for NUMA-based machines/SoCs, b/c correct cpu tolopolgy is critical for the kernel numa code to DTRT. -- note: ACPI-based NUMA specification, SRAT, solves most of the issue except for the next field & its correlation to SRAT-cpu-values. -- MPIDR Aff<x> fields. On ARMv8, unlike ARMv7, MPIDR contents are *implementation specific* -- an architected register w/un-architected contents. duh! ARMv7 had a simple spec that lower 8-bits(Aff0) were cores, next 8 bits(Aff1) were 'clusters' that shared L2 caches; I think the Aff3 field was for shared L3. But since 99.999999% of ARMv7's are single socket, relative small core counts, it was easy to make the MPIDR register go from unspecified to 'we all agree to do it this way' ... b/c they happen to do it that way. On ARMv8, the upstream topology code in interpreting Aff1 as the socket count, when in fact, it is a 'cluster' index, indicating shared caches. If you run the same command on a RHELSA kernel, you will find proper values, because RHELSA is carrying a patch that works for Xgene & Seattle. IIRC, that patch will fail for ThunderX, and will need further modification. jcm has a to-do on this issue w/ARM & to come up with an ACPI-based solution that will yield the equivalent of x86's cpu-id -based, cpu topology information. [read the arch/x86/kernel/topology.c code to learn the details, and search the Intel tech pages for a paper on their topology architecture wrt cpu-id probing. The DT-based solution is TBD, and the DT-huggers can resolve it with yet-another-specification-to-cpu-DT. Until ARM & it's partners determine/specify/require an architected cpu topology specification, this problem becomes a per-SoC, 'quirk' to the arch/arm64/kernel/topology.c support. So if I read correctly Don's comment #3 then the problem is mostly in stuff exported by kernel in /sys and for patched kernels (e.g. RHELSA) lscpu generates valid output. Right? ... then it's time to reassign to kernel :-) Richard, it would be nice to have /sys and /proc dump from the system, in upstream tree we have a script https://raw.githubusercontent.com/karelzak/util-linux/master/tests/ts/lscpu/mk-input.sh to create a tarball. Please, send me (or add to BZ) the tarball. Created attachment 1068857 [details]
proc.tar.gz
Created attachment 1068858 [details]
sys.tar.gz
Created attachment 1068859 [details]
mustang.tar.gz
I should have read the whole comment before posting those
previous attachments. Attached is the output from the command
sudo ./mk-input.sh mustang
This is an old one, and while not fixed on the mustang, should be fixed on any aarch64/ACPI machine with a correct PPTT. It maybe worth closing this. Thanks. I'm going to close this then. I think the best approach would be to reopen for specific machines that don't have a correct PPTT is problems still show up. |