Re: CONFIG_NO_HZ_FULL restricts cpu usage to the equivalent of one in 4.2

[Andy Lutomirski <luto@amacapital.net>]

On 07/15/2015 09:27 AM, Ken Moffat wrote:
> New title, I originally posted this last night but I've now made
> a little progress in identifying what changed.  Previous thread was
> labelled for AMD Phenom, but it is more general.  CC'ing Jeff
> because he replied to the original, I guess he probably won't be
> interested after this.
>
> Yesterday was the first day I had done any real compiling with
> 4.2-rc.  I started out using -rc1, and make -j4 on a recent LFS/BLFS
> system (gcc-5.1.0, make-4.1, etc).  I wanted to start trying to
> build kde5, and I expected a lot of issues.  What I did not expect
> was that qt5 would build as if I was using -j1.
>
> Examination eventually identified that with 4.2-rc1 and 4.2-rc2,
> make ran the number of jobs I had specified, but the total of the
> CPU percentages ('top' from procps-ng-3.3.10) maxed out at 100%.  On
> 4.1 kernels the percentage with -j4 maxes out at 400% (my machine
> has 4 cores).  I suspected either an unfortunate choice in 'make
> oldconfig', or something specific to an AMD Phenom / gcc-5.1.
>
> Today I have tried make -j4 on two other machines with 4.2-rc
> kernels [ building the current git stable release ].  On my i3
> SandyBridge everything was fine, CPU usage approached 400%.  On my
> AMD A10-7850K I have the same problem as on the phenom.  Not
> surprising, I began by using the Phenom config when I got the A10,
> then adapted it to suit, whereas the i3 has much less memory so I
> haven't made many changes since I got it.
>
> Comparing the configs for the i3 and the A10, the first thing which
> looked as if it might be relevant was the _CPU_ACCOUNTING choices.
> Those on the A10 seem to be driven from CONFIG_NO_HZ_FULL so I began
> by changing that to CONFIG_NO_HZ_IDLE.  Payday ;-)  make -j4 now
> approaches 400% CPU usage.
>
> The config differences follow.  Perhaps it is actually one of the
> subsequent choices that is the problem.  And I guess it could still
> be a gcc-5.1 issue.
>

Before going nuts bisecting, it could be worth running perf record -a -g 
-e cycles (or perhaps -e task-clock instead of -e cycles).  It could 
also be worth manually sampling /proc/PID/stack a few times for a 
process that isn't making as much progress as it should.

--Andy