Testers for inxi/pinxi redone -C CPU logic... huge internal changes
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
fourtysixandtwo, yeah, that thought crossed my mind too. Glad to have fresher eyes than mine looking at this.
pinxi 3.3.09-28 features that change, and also a massive optimization, which so far in testing on some systems knocked off a whopping 6.2 seconds (the more cores, the more time it knocks off, seems to be cpu / platform dependent too). Another one it knocked off about 0.4 seconds. Mine it knocked off I think about 0.2 seconds.
As you can see, despite doing a ton more work, pinxi -C is running faster than inxi -C, consistently.
I'll be taking a look to see if there are any more low hanging optimization fruits to be had, I suspect I can knock off another 10% or so, maybe, if I am always running stuff that only needs to run in specific cases.
With the caches moved to Topology line, that means all CPUs that have /sys data will show on the Topology line now, so it will also be more consistent for -Ca. Non Linux and legacy Linux/hardware will show roughly what they used to show, though I'm removing more of the somewhat nonsensical hacks as I become more sure that they are not good ideas in general.
This is the system that dropped 6 (SIX) plus seconds with those two optimizations:
Assuming reasonable code logic, pinxi should have been faster than inxi despite having a lot more code running because pinxi was continuously optimized during this process, all hash/array movements were switched to fully by reference, whereas inxi was doing a lot of them in CPU by copying over and over, that was one of the legacy issues I corrected in the code from the start.
If I can consistently drop 100ths of seconds from a specific optimization, I'll usually go for it, and if 1000ths in loops, usually too. So there may be some more time to get now that the overall logic is working. I did have to sacrifice some error handling ability however with part of this optimization, but I think it should be ok.
Certain types of hardware/platforms seem to run slightly slower with pinxi -C than inxi -C, that may be a function of those being virtualized, I'm not sure, I'll see if I can pinpoint the slowdown there. About 0.25 seconds slower. That may be because the guest has to query the host for this data, which may suffer some lag, whereas on systems where it gets it directly, it actually ends up being faster.
Note that there is an oddity with flags, with -Cf, the flags item moves, but with -Cx, the shorter flag list is in a different spot. However, if I move the -f flags to be the same spot, it would push the topology down under it, which would not be very intuitive I think.
This 'feels' much better to me, and fixes a lot of super old random weird output decisions that I can't for the life of me remember or explain.
Note that is a new filter option,--zv/--filter-vulnerabilities, and the old --filter-labels --filter--uuids now have terser forms --zl --zu
This is starting to really shape up nicely now I think.
Take it for a spin after updating and let me know if you see anything else the seems off or out of place.
But this is starting to feel 'done' almost to me, barring any suggestions, so I think I'll spend some time on optimizations and check to see if anything is slowing things down due to weak or redundant or unnecessary logic, then fix those issues.
It would be cool if I could get pinxi -C to be always faster than inxi -C on all systems, right now it's faster on most, which is not what I expected given now much more complicated the logic is now than before.
I'm still seeing some significant slowdowns between 'pinxi' alone and 'inxi' alone however, so I'll see where that is coming from, something else might have slipped in unnoticed that is slowing it down besides CPU logic.
On this ancient system, pinxi shows much improved time. (Wall-time slightly better, but sys-time cut by more than half.)
inxi:
Code:
~$ inxi --version | grep ^inxi
inxi 3.3.09-00 (2021-11-22)
~$ time inxi -MCazy
Machine:
Type: Unknown Mobo: ASUSTeK model: P5A-B v: REV 1.XX
serial: <superuser required> BIOS: Award
v: ASUS P5A-B Revision 1011 Beta 005 date: 05/02/02
CPU:
Info: Single Core model: AMD-K6 3D bits: 32 type: UP arch: K6-2 family: 5
model-id: 8 stepping: C (12) microcode: N/A cache: L1: 64 KiB L2: 64 KiB
flags: N/A bogomips: 570
Speed: 285 MHz min/max: N/A Core speed (MHz): 1: 285
Vulnerabilities: Type: itlb_multihit status: Not affected
Type: l1tf status: Not affected
Type: mds status: Not affected
Type: meltdown status: Not affected
Type: spec_store_bypass status: Vulnerable
Type: spectre_v1
mitigation: usercopy/swapgs barriers and __user pointer sanitization
Type: spectre_v2
mitigation: Full generic retpoline, STIBP: disabled, RSB filling
Type: srbds status: Not affected
Type: tsx_async_abort status: Not affected
real 0m12.665s
user 0m10.892s
sys 0m1.301s
latest pinxi:
Code:
~$ ./pinxi --version | grep ^pinxi
pinxi 3.3.09-29 (2021-12-04)
~$ time ./pinxi -MCazy
Machine:
Type: Unknown Mobo: ASUSTeK model: P5A-B v: REV 1.XX
serial: <superuser required> BIOS: Award
v: ASUS P5A-B Revision 1011 Beta 005 date: 05/02/02
Use of uninitialized value in numeric ne (!=) at ./pinxi line 10613.
CPU:
Info: model: AMD-K6 3D bits: 32 type: UP arch: K6-2 family: 5 model-id: 8
stepping: C (12) microcode: N/A bogomips: 570
Topology: cpus: 1x cores: 1 cache: 64 KiB note: check
Speed (MHz): 285 min/max: N/A core: 1: 285
Flags: N/A
Vulnerabilities:
Type: itlb_multihit status: Not affected
Type: l1tf status: Not affected
Type: mds status: Not affected
Type: meltdown status: Not affected
Type: spec_store_bypass status: Vulnerable
Type: spectre_v1
mitigation: usercopy/swapgs barriers and __user pointer sanitization
Type: spectre_v2
mitigation: Full generic retpoline, STIBP: disabled, RSB filling
Type: srbds status: Not affected
Type: tsx_async_abort status: Not affected
real 0m10.444s
user 0m9.575s
sys 0m0.469s
PS. The error message (highlighted in red above) is also showing up when I run pinxi on my wife's Dell DM061, but not on my Dell Precision490. I'm thinking perhaps an empty value for "$topo->{'threads'}" ..?
Last edited by JayByrd; 12-04-2021 at 09:30 PM.
Reason: detail, and additional error info.
Couple of errors have popped back in with the -29 version I see.
Code:
# time ./inxi -Caz
Can't use an undefined value as a HASH reference at ./inxi line 9595.
real 0m33.888s
user 0m32.350s
sys 0m1.140s
time ./pinxi -Caz
Use of uninitialized value in pattern match (m//) at ./pinxi line 8454.
CPU:
Info: single core model: 486 bits: N/A type: UP arch: N/A family: 4
model-id: N/A microcode: N/A cache: N/A bogomips: N/A
Speed: N/A min/max: N/A core: No per core speed data found.
Flags: N/A
Vulnerabilities: No CPU vulnerability/bugs data available.
real 0m34.402s
user 0m32.770s
sys 0m1.250s
Code:
# time ./inxi -Ca
CPU: Info: Single Core model: AMD Athlon 64 3000+ socket: 754 bits: 64 type: UP arch: K8 family: F (15) model-id: C (12)
stepping: 0 microcode: 3A cache: L1: 128 KiB L2: 512 KiB
flags: lm nx pae sse sse2 bogomips: 4004
Speed: 2000 MHz min/max: 1000/2000 MHz base/boost: 2000/2400 volts: 1.5 V ext-clock: 200 MHz Core speed (MHz):
1: 2000
Vulnerabilities: Type: itlb_multihit status: Not affected
Type: l1tf status: Not affected
Type: mds status: Not affected
Type: meltdown status: Not affected
Type: spec_store_bypass status: Not affected
Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
Type: spectre_v2 mitigation: Full AMD retpoline, STIBP: disabled, RSB filling
Type: srbds status: Not affected
Type: tsx_async_abort status: Not affected
real 0m0.956s
user 0m0.488s
sys 0m0.104s
# time ./pinxi -Ca
Use of uninitialized value in numeric ne (!=) at ./pinxi line 10613.
CPU:
Info: model: AMD Athlon 64 3000+ socket: 754 bits: 64 type: UP arch: K8
family: F (15) model-id: C (12) stepping: 0 microcode: 3A bogomips: 4004
Topology: cpus: 1x cores: 1 cache: L1: 128 KiB
desc: d-1x64 KiB; i-1x64 KiB L2: 512 KiB desc: 1x512 KiB
Speed (MHz): 1000 min/max: 1000/2000 base/boost: 2000/2400 volts: 1.5 V
ext-clock: 200 MHz core: 1: 1000
Flags: lm nx pae sse sse2
Vulnerabilities:
Type: itlb_multihit status: Not affected
Type: l1tf status: Not affected
Type: mds status: Not affected
Type: meltdown status: Not affected
Type: spec_store_bypass status: Not affected
Type: spectre_v1
mitigation: usercopy/swapgs barriers and __user pointer sanitization
Type: spectre_v2
mitigation: Full AMD retpoline, STIBP: disabled, RSB filling
Type: srbds status: Not affected
Type: tsx_async_abort status: Not affected
real 0m0.941s
user 0m0.483s
sys 0m0.094s
Code:
$ time ./inxi -Ca
CPU: Info: Quad Core model: ARMv7 v7l variant: cortex-a53 bits: 32 type: MCP arch: v7l family: 7 model-id: 0 stepping: 4
features: Use -f option to see features bogomips: 307
Speed: 1200 MHz min/max: 600/1200 MHz Core speeds (MHz): 1: 1200 2: 1200 3: 1200 4: 1200
Vulnerabilities: No CPU vulnerability/bugs data available.
real 0m1.465s
user 0m0.946s
sys 0m0.170s
$ time ./pinxi -Ca
Use of uninitialized value in numeric ne (!=) at ./pinxi line 10611.
CPU:
Info: model: ARMv7 v7l variant: cortex-a53 bits: 32 type: MCP arch: v7l
family: 7 model-id: 0 stepping: 4 bogomips: 76
Topology: cpus: 1x cores: 4 cache: N/A
Speed (MHz): avg: 1200 min/max: 600/1200 cores: 1: 1200 2: 1200 3: 1200
4: 1200
Features: Use -f option to see features
Vulnerabilities: No CPU vulnerability/bugs data available.
real 0m1.747s
user 0m1.229s
sys 0m0.170s
Those were both trying to work with undefined values, as you suspected.
Perl always keeps you honest in that way.
This is my starting to cut out more code and merging stuff, but forgetting that some of those tests for null were there for a reason, heh.
Should be fixed in 3.3.09-30
I'll try testing on some of my test sys/cpuinfo pairs as well.
I've been cutting out a lot of extra logic today, and merged some stuff, of course no machines I tested on had the data yours do, so appreciate it.
Most fixes aren't too major so it's going to be smaller corner case stuff like this I hope, keeping my fingers crossed, I cut out a fair chunk of stuff today.
Still getting used to the move, correctly, of Topology: to under Info:, on your arm device, I was like, oh, no, topolgoy didn't work!@!
For what is worth, here in my output. The Topology is now showing as you indicated above. Still shows L3 cache, maybe there is one. To my untrained eye it is all perfect.
chrisretusn, not quite perfect: https://www.cpu-world.com/CPUs/K10/A...42GM.htmlLevel 1 cache size ? 4 x 64 KB 2-way set associative instruction caches
4 x 64 KB 2-way set associative data caches
Level 2 cache size ? 4 x 512 KB 16-way set associative exclusive caches
Level 3 cache size None
However, I suspect this is the system lying to pinxi unfortunately.
If you can confirm this with these:
Code:
for i in $(ls /sys/devices/system/cpu/{cpu*/topology,cpu*/cpufreq,cpu*/cache/index*,smt}/*);do echo -n "$i::";cat $i;done > cpu-sys.txt
cat /proc/cpuinfo > cpuinfo.txt
# and also:
pinxi -Ca --dbg 39 > pinxi-39.txt
I remember earlier in the thread seeing a phantom L3 cache, but I had assumed that was coming from dmidecode by accident, but your data seems to indicate that it's coming from the cache data somewhere else:
Code:
L3: 512 KiB
the lack of 'desc:' there suggests it came from either /proc/cpuinfo or from dmidecode.
I will have to check that logic to make sure neither can leak in by accident, looks however like it is, unless it's a weird /sys reading that I failed to properly handle. I'm suspecting this one is a bug in pinxi.
chrisretusn, not quite perfect: https://www.cpu-world.com/CPUs/K10/A...40WFK42GM.html 1 cache size ? 4 x 64 KB 2-way set associative instruction caches
4 x 64 KB 2-way set associative data caches
Level 2 cache size ? 4 x 512 KB 16-way set associative exclusive caches
Level 3 cache size None
However, I suspect this is the system lying to pinxi unfortunately.
If you can confirm this with these:
Code:
for i in $(ls /sys/devices/system/cpu/{cpu*/topology,cpu*/cpufreq,cpu*/cache/index*,smt}/*);do echo -n "$i::";cat $i;done > cpu-sys.txt
cat /proc/cpuinfo > cpuinfo.txt
# and also:
pinxi -Ca --dbg 39 > pinxi-39.txt
The link has some extra stuff "Level" at the end. Fixed in my quote above
Here is my results:
Code:
~# ./pinxi --version | grep ^pinxi
pinxi 3.3.09-30 (2021-12-04)
~# for i in $(ls /sys/devices/system/cpu/{cpu*/topology,cpu*/cpufreq,cpu*/cache/index*,smt}/*);do echo -n "$i::";cat $i;done > cpu-sys.txt
cat /proc/cpuinfo > cpuinfo.txt
cat: '/sys/devices/system/cpu/cpu0/cpufreq/stats:': No such file or directory
cat: reset: No such file or directory
cat: time_in_state: No such file or directory
cat: total_trans: No such file or directory
cat: trans_table: No such file or directory
cat: '/sys/devices/system/cpu/cpu1/cpufreq/stats:': No such file or directory
cat: reset: No such file or directory
cat: time_in_state: No such file or directory
cat: total_trans: No such file or directory
cat: trans_table: No such file or directory
cat: '/sys/devices/system/cpu/cpu2/cpufreq/stats:': No such file or directory
cat: reset: No such file or directory
cat: time_in_state: No such file or directory
cat: total_trans: No such file or directory
cat: trans_table: No such file or directory
cat: '/sys/devices/system/cpu/cpu3/cpufreq/stats:': No such file or directory
cat: reset: No such file or directory
cat: time_in_state: No such file or directory
cat: total_trans: No such file or directory
cat: trans_table: No such file or directory
~# ./pinxi -Ca --dbg 39 > pinxi-39.txt
h2-1, for a little more ARM content: Raspberry Pi 4B with latest SlackwareARM -current (32 bit) (Nov 30 updates) with Sarpi kernel packages 5.15.5 of Nov 28
Code:
# uname -a
...slackwarearm 5.15.5-v7l-sarpi4 #1 SMP Fri Nov 26 11:06:48 GMT 2021 armv7l BCM2711 GNU/Linux
With the exception of below everything looks fine with -30 so far.
Still seeing the following error on the 486. Also any reason it's not picking up the bogomips from /proc/cpuinfo?
Code:
# ./pinxi --version | grep ^pinxi
pinxi 3.3.09-30 (2021-12-04)
# time ./pinxi -Caz
Use of uninitialized value in pattern match (m//) at ./pinxi line 8454.
CPU:
Info: single core model: 486 bits: N/A type: UP arch: N/A family: 4
model-id: N/A microcode: N/A cache: N/A bogomips: N/A
Speed: N/A min/max: N/A core: No per core speed data found.
Flags: N/A
Vulnerabilities: No CPU vulnerability/bugs data available.
real 0m34.127s
user 0m32.600s
sys 0m1.140s
TheTKS, thanks for the ARM data, looks about right. Raspberry pi had a lot of fixes over past year to get everything there working again after they changed some key device types which were very hard to detect (their bluetooth in particular was very difficult to detect, inxi has a pi only detection running to catch that now, nobody else that I am aware of in the world uses that type of bluetooth device, not usb, some type of odd serial device).
That pi shows the pinxi speed optimizations working very well, if you notice what inxi thinks the base speeds are vs what pinxi shows them as, that's a big improvement.
I was supposed to get access to some serious ARM server hardware, but it hasn't happened yet.
chrisretusn, that L3 has to be coming from the dmidecode fallback, can you post the output for this:
pinxi -Ca --dbg 2
then cut out the blocks start with 4 or 7, that might show me what is going on there, I think it's some alternate value that is tripping pinxi up there.
I suspect that there is some matching syntax that is getting thrown off.
Your /proc/cpuinfo has only the expected 'cache size:' item, and your sys data has only caches level 1i, 1d, and 2, no 3.
So this has to be coming from dmidecode somehow I believe, there's no other explanation that makes sense, unless I'm missing something obvious internally.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
To my untrained eye it is all perfect. 
