ghw
ghw copied to clipboard
jaypipes
Support for ARM
Presently CPU info on ARM is empty(cpu (0 physical packages, 0 cores, 0 hardware threads)) as there are many fields missing in ARM's /proc/cpuinfo.
Sample ARM /proc/cpuinfo
processor : 0
BogoMIPS : 108.00
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3
processor : 1
BogoMIPS : 108.00
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3
processor : 2
BogoMIPS : 108.00
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3
processor : 3
BogoMIPS : 108.00
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3
Hardware : BCM2835
Revision : c03111
Serial : 100000002f8e83b3
Model : Raspberry Pi 4 Model B Rev 1.1
More samples can be found here https://github.com/shirou/gopsutil/issues/881
Even if we change the implementation to ignore missing fields, the values are of available fields are numeric. They need to be converted into human readable string for meaning usage.
Seems the right way to do this is to use combination of lscpu and /proc/cpuinfo results. As described here http://suihkulokki.blogspot.com/2018/02/making-sense-of-proccpuinfo-on-arm.html, the lscpu is actively maintained and provides reliable information. On my ARM platform(RaspberryPi) I can confirm the presence of lscpu. I believe it would be available in other ARM platforms as well.
Is it okay to add support for ARM with help of of both lscpu and /proc/cpuinfo?
Is it okay to add support for ARM with help of of both
lscpuand/proc/cpuinfo?
Hi @sivachandran! Yes, absolutely it would be awesome to add support for ARM. I don't have time to work on this at the moment, though. Are you interested in contributing here?
on mac m1 (arm64)
Error getting GPU info: gpuFillInfo not implemented on darwin<nil>
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x8 pc=0x1045fa830]
goroutine 1 [running]:
main.main()
I think that the rest will not work either
on mac m1 (arm64)
Error getting GPU info: gpuFillInfo not implemented on darwin<nil> panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x2 addr=0x8 pc=0x1045fa830] goroutine 1 [running]: main.main()I think that the rest will not work either
Unfortunately, we only support block device information discovery in Darwin at the moment. Nothing to do with ARM :)
/proc/cpuinfo seems to be variable across platforms, should we use sysfs (like lscpu) instead ?
/proc/cpuinfo seems to be variable across platforms, should we use sysfs (like lscpu) instead ?
I would definitely be open to this idea, @rockrush.
/proc/cpuinfo seems to be variable across platforms, should we use sysfs (like lscpu) instead ?
I would definitely be open to this idea, @rockrush.
I'm working on it, hope to finish by 3.6. Due to lack of (multi-socket) hardware, qemu(machine type virt-6.2) is used. The change would inpact on currently working platforms, so needs been tested on both ARM64 and x86(may be more) before merged safely.
Test env: 2 cpus, with 2 cores each, that supports 2 threads. Not finished yet ... rockrush@debian-aarch64:~/ghw$ ./ghwc cpu cpu (2 physical packages, 4 cores, 8 hardware threads) physical package #36 (2 cores, 4 hardware threads) processor core #56 (2 threads), logical processors [] processor core #116 (2 threads), logical processors [] physical package #176 (2 cores, 4 hardware threads) processor core #196 (2 threads), logical processors [] processor core #256 (2 threads), logical processors []
