[SOLVED] KSysGuard claims only 1 of 8 CPUs are being used.

[xplosivelugnut]

And I believe it.

As an example, if I compile my kernel with a make -j16, I expect to see all 8 of the 2600K's CPUs to plateau at %100 on KSysGuard just like it does on another hyper threaded quad core machine I have. KSysGuard claims that only CPU 1 is being used and the compile time seems to agree with that. It takes far longer than it does on the other machine (nigh identical configs).

And it's not just an issue where individual programs can't use multiple CPUs, it seems the whole system is restricted to beating on CPU 1.

To clarify further, KSysGuard does display all 8 CPUs. Only CPU 1 ever gets used, the other 7 stay at a rock solid 0%.

A supplementary snippet of dmesg output:

# dmesg | grep x86
[ 0.000000] x86/fpu: xstate_offset[2]: 0240, xstate_sizes[2]: 0100
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers'
[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 0x340 bytes, using 'standard' format.
[ 0.000000] x86/fpu: Using 'eager' FPU context switches.
[ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT
[ 0.008209] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
[ 0.032309] x86: Booting SMP configuration:
[ 0.061832] x86: Booted up 1 node, 8 CPUs
[ 2.863953] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 355.11 Wed Aug 26 16:35:41 PDT 2015

dmesg is also getting CPU over temp messages frequently. I suppose using one thread causes the processor to run excessively hot?

Thanks!

EDIT: SOLVED
It's was bug 559382.

[huelter]

Have you compiled your kernel with SMP support?

[Hu]

That is a useless use of cat. You get the same effect with grep SMP /usr/src/linux/.config. As far as I know, OP would not have multiple cores listed in /proc/cpuinfo if his kernel was not SMP.

OP: what does taskset -p $$ show?

[xplosivelugnut]

Just to confirm.

# grep SMP /usr/src/linux.config
CONFIG_X86_64_SMP=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_SMP=y
CONFIG_PM_SLEEP_SMP=y

And then there's this.

# taskset -p $$
pid 2918's current affinity mask: 1

I've also noticed a conspicuous lack of 8 tuxes at the top of my screen when the kernel is booting up. There are no tuxes at all.

Also, thanks for the tip on how to properly use grep. I've been guilty of piping cat's output into grep as well.

EDIT:

I did a taskset -p $$ on the other machine I mentioned and the affinity mask returned ff. After reading up on what the mask represents, this seems to point to a scheduler issue. Not yet sure how to deal with that.

[Josef.95]

Sounds like to Bug 559382

[xplosivelugnut]

Yup, that was it. Not sure if that fix is actually a fix or just a work around, but I'm firing on all cores now.

Thanks!