Ok, would have been strange but at least worth a try.
Just out of curiosity, did you try an older kernel on the remote machine?

I'll dig in your config a little bit, but at the moment i don't really have an idea what i'm looking for._________________Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.

Interesting. From the posts made prior to my most recent one above, I thought the problem was that the build would use only 7 cores out of 8 installed/detected cores on the system, which is why I looked at the --load-average, since that could prevent make from launching job #8. From the more recent post, I now understand that it is using exactly one core and that the core it uses is core #7. That is strange. What is the output of taskset -p $$, as run from the same prompt that launched the emerge that uses only 1 core?

I've moved your kernel to a KVM, with only the changes required to get it to boot there.

Booting it, going to the kernel tree and runnning

Code:

make clean
make -j4

shows it use both available cores.

Code:

emerge sys-devel/gcc

builds gcc on both available cores.

I can add a few more cores to the KVM if you think it matters but I'm fairly sure from the demonstration that the problem is not the kernel.
You can review the config I ended up with and diff it with your own._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

After we didn't found any issue with the kernel itself and in 4.4.52 it occurs too, i looked into the whole server configs.

According to @jburns post, i looked to any init.d's and saw for some reason, sshd was launched with taskset -c 7.
This must be done with a misconfigured sed command i run weeks ago, because i'm launching some stuff to specific cores (frame calculation).

Ok no worries, i added a sshd restart to crontab, and logged off from all running shell sessions.
After coming back again, suprise suprise, any make is not running on core7 anymore. It's core0 now.

Investigating this again and saw, dcron is fixed via taskset -c 0 to core0.
So with that, restarting sshd over dcron wasn't successful.

Tried restarting dcron with no fixed cores, but for some reason, it worked first after a remote restart.

Now, after all, it is fixed and the thread could be marked as solved.
Finally.

If i could, i would spend some coffee for your effort.

Anyway, i've a memory leak with nftables beside the core "problem", maybe we'll see us in the other thread.