Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753232AbbGOQ12 (ORCPT ); Wed, 15 Jul 2015 12:27:28 -0400 Received: from know-smtprelay-omc-7.server.virginmedia.net ([80.0.253.71]:39467 "EHLO know-smtprelay-omc-7.server.virginmedia.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751961AbbGOQ1Z (ORCPT ); Wed, 15 Jul 2015 12:27:25 -0400 X-Originating-IP: [81.106.150.188] X-Spam: 0 X-Authority: v=2.1 cv=JuUM15MC c=1 sm=1 tr=0 a=DGj713NdaxKrsjjgQne7PA==:117 a=DGj713NdaxKrsjjgQne7PA==:17 a=NLZqzBF-AAAA:8 a=yEdEr6MRgwAA:10 a=IkcTkHD0fZMA:10 a=zOBTXjUuO1YA:10 a=pZuwphcSgDdZya0uqb0A:9 a=cuuUQ-e8BhtRqCK7:21 a=LtKbnCjTDRlUBuUo:21 a=QEXdDO2ut3YA:10 Date: Wed, 15 Jul 2015 17:27:13 +0100 From: Ken Moffat To: linux-kernel@vger.kernel.org Cc: Jeff Epler Subject: CONFIG_NO_HZ_FULL restricts cpu usage to the equivalent of one in 4.2 Message-ID: <20150715162713.GA29360@milliways> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3310 Lines: 84 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. --- config-4.2-initial 2015-07-15 16:25:12.548005751 +0100 +++ config-4.2-speed-ok 2015-07-15 17:00:50.919998703 +0100 @@ -104,11 +104,8 @@ CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set -# CONFIG_NO_HZ_IDLE is not set -CONFIG_NO_HZ_FULL=y -CONFIG_NO_HZ_FULL_ALL=y -CONFIG_NO_HZ_FULL_SYSIDLE=y -CONFIG_NO_HZ_FULL_SYSIDLE_SMALL=4 +CONFIG_NO_HZ_IDLE=y +# CONFIG_NO_HZ_FULL is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y @@ -116,7 +113,9 @@ # CPU/Task time and stats accounting # CONFIG_VIRT_CPU_ACCOUNTING=y +# CONFIG_TICK_CPU_ACCOUNTING is not set CONFIG_VIRT_CPU_ACCOUNTING_GEN=y +# CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y @@ -131,7 +130,6 @@ # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y CONFIG_CONTEXT_TRACKING=y -CONFIG_RCU_USER_QS=y CONFIG_CONTEXT_TRACKING_FORCE=y # CONFIG_TREE_RCU_TRACE is not set CONFIG_RCU_NOCB_CPU=y Anyway, I'll start a bisection. But it might take me a few days, this is not a convenient time (somehow, kernel issues which need bisection always come at a bad time for me). ĸen -- This one goes up to eleven! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/