Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S944931AbcJSPXM (ORCPT ); Wed, 19 Oct 2016 11:23:12 -0400 Received: from mail-oi0-f43.google.com ([209.85.218.43]:34685 "EHLO mail-oi0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S944160AbcJSPXJ (ORCPT ); Wed, 19 Oct 2016 11:23:09 -0400 MIME-Version: 1.0 In-Reply-To: References: From: =?UTF-8?Q?J=C3=B6rg_Otte?= Date: Wed, 19 Oct 2016 13:07:08 +0200 Message-ID: Subject: Re: [4.9-rc1] Build-time 2x slower To: Linus Torvalds Cc: Michal Marek , Sedat Dilek , Ming Lei , LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id u9JFNJRh017997 Content-Length: 2188 Lines: 63 2016-10-18 19:19 GMT+02:00 Linus Torvalds : > On Tue, Oct 18, 2016 at 9:49 AM, Jörg Otte wrote: >> On Tue, Oct 18, 2016 at 12:04 AM, Sedat Dilek wrote: >>> >>> not sure whom to address on this issue. >>> >>> I have built Linux v4.9-rc1, v4.8.2 and v4.4.25 kernels (in this >>> order) this morning. >>> >>> Building a Linux v4.8.2 under Linux v4.9-rc1 took two times longer. >>> >>> As usually I build with 2 parallel-make-jobs. >>> This takes approx. 30mins. >>> Under Linux v4.9-rc1 it took approx. an hour. >>> >>> My system is a Ubuntu/precise AMD64 (WUBI installation). >>> I use my normal build-environment. >> >> I can confirm the problem. I use 3 build jobs in parallel >> and the kernel build takes 2,5 times longer. >> >> I'm only seeing 1 (of 4) cores are running with max frequency. >> The other are running in minimum frequency. And this seems not >> to be limited to build jobs however. >> >> The last known good kernel for me is ..-4.8.0-14604-g29fbff8 > > Well, there are a few merges in 4.9-rc1 since that > 4.8.0-14604-g29fbff8 version, but the obvious ones are my pulls from: > > Michal Marek (2): > kbuild updates > misc kbuild changes > > (My merge commit ID's are 50cff89837a4 and 84d69848c97f) with > everything else looking like "normal code updates". > > Michal: a 2.5x slowdown of the kernel build was presumably *not* intentional. > > I'm not seeing anything obvious, but if it's spending a lot more time > in fixdep, then it's that "strstr()" change. That commit seems to > assume that strstr() is fast, which is a debatable assumption and > might be wrong in some environments. > > But even with a "strstr()" written by a sloth that was dropped on its > head a few too many times when young, I can't see it being *that* much > slower. > > Can you do just a silly > > perf record make -j8 > > of the bad build, and see if something stands out when you do "perf report"? > > But maybe Michal has some ideas. > > Linus Additional info: I usally use schedutil governor. If I switch to performance governor problems go away. Maybe a cpufreq problem? Jörg