there seems to be an issue where the cpu is under-utilized while manually compiling ( cmake --build build -j$(getconf _NPROCESSORS_ONLN) ). all core frequencies look fine but utilized at less than ~5%. building pkgs with yay seems ok though… i have checked around the web but cant find anything really related to my case. any and all help is welcomed!
H/W info: https://0x0.st/XYf9.txt
update 1:
the problem its intermittent and now yay exhibits the same symptoms .
Have you edited /etc/makepkg.conf ??
Change the line:
MAKEFLAGS="-j$(nproc)"
To match the above. It is line 53.
First off welcome @Ktrl-sama could you describe the issue clearly, what you have wrote and posted means zero to me ( and possibly others)
hi! thanks for replying. i have now added your suggestion as its a little nifty one. but i specifically specified cmake --build build -j$(getconf _NPROCESSORS_ONLN). so it should have worked?
No idea, I only use yay and rarely compile manually.
Well getconf _NPROCESSORS_ONLN returns the correct number of cores for me, so it should work.
hi!. the issue is the cpu is not being saturated 100% when compiling and building stuff from src. i have tried building devolutionX and it has taken more than 11 hours. where i see all core being used at ~5% capacity. i tried building others and it was the same. but yay builds stuff just fine.
I was gonna say something buy yer not sure where to start exvr[yt a nre user
Pretty sure I meant to type encounter
1st line I have no idea so sorry to anyone who reads it.
yes devolutionX. but i clone it from src using git clone. then i cmake -S. -Bbuild -DCMAKE_BUILD_TYPE=Release -Wno-dev and cmake --build build -j$(getconf _NPROCESSORS_ONLN). this is per their build wiki. and i honestly have always done it this way on every other distro i use.
Space between -j $ ???
Other than that it is in aur, so will build with makepkg.
yes i tried with and without the space. sadly it didn’t make a difference. aur is amazing but i likes building things =)
This worked for me:
cmake --build build -j $(nproc)
i kept re-trying and it worked once. now yay is having the same issues. this might ended up being one of those illusive big foot journeys…
im beginning to think there’s something in bios or straight up cpu degradation… i will have to test on debian and maybe even fedora too and see. i can also try a different kernel i guess too
Compiling can also be i/o intense. If you get i/o overload this results in low cpu load, as it is most of the time waiting for i/o to finish. You might check if everything is ok with the disks, not full, not broken…
i am back with updates…
after checking bios and everything mentioned here with no help. i came across a page https://discovery.endeavouros.com/hardware/intel/2021/03/ that mentioned this cmd
sudo modinfo -p i915
this command will list compatible kernel parameter for your cpu. i then added these i915.enable_psr=0 i915.enable_dc=0 i915.disable_power_well=1 to /etc/default/grub and to also /etc/kernel/cmdline. then just because… i also added this to my .zshrc
// function to set desired cpu governor
// available cpufreq governors: conservative ondemand userspace powersave performance schedutil
function setcpu () {
if [ -f /usr/bin/cpupower ]; then
sudo cpupower frequency-set -g performance
echo “Set cpu to performance!”
else
echo “cpupower not found”
fi
}
after these additions i can finally compile with the force on my side 
i915 mod parameters are related to GPU, not CPU. They have influence on sleep modes and sync, but i don’t see any connection to CPU performance. As these i915 have various issues that strongly depend on specific processor generation, it would be interesting to see your lscpu here.
Setting the cpu governor does have influence on cpu power, that makes sense.
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 36 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Vendor ID: GenuineIntel
Model name: Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz
CPU family: 6
Model: 42
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Stepping: 7
CPU(s) scaling MHz: 96%
CPU max MHz: 3700.0000
CPU min MHz: 1600.0000
BogoMIPS: 6588.01
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 ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon
pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcn
t tsc_deadline_timer aes xsave avx lahf_lm epb pti ssbd ibrs ibpb stibp xsaveopt dtherm ida arat pln pts md_clear flush_l1d
Caches (sum of all):
L1d: 128 KiB (4 instances)
L1i: 128 KiB (4 instances)
L2: 1 MiB (4 instances)
L3: 6 MiB (1 instance)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-3
Vulnerabilities:
Gather data sampling: Not affected
Itlb multihit: KVM: Mitigation: VMX unsupported
L1tf: Mitigation; PTE Inversion
Mds: Mitigation; Clear CPU buffers; SMT disabled
Meltdown: Mitigation; PTI
Mmio stale data: Unknown: No mitigations
Reg file data sampling: Not affected
Retbleed: Not affected
Spec rstack overflow: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Retpolines; IBPB conditional; IBRS_FW; STIBP disabled; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
Srbds: Not affected
Tsx async abort: Not affected
changing the governor had no effect for me before the changes… since the cpu is both cpu/gpu it made sense to me that there can be some relation…
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.