linux-kernel - Re: [4.9-rc1] Build-time 2x slower

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADDKRnBZ7CjTq4x1u9pfK_uqVmXsBsXv0mL65yr0eEmMOH8Asw@mail.gmail.com>
Date:   Wed, 19 Oct 2016 13:07:08 +0200
From:   Jörg Otte <jrg.otte@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Michal Marek <mmarek@...e.com>,
        Sedat Dilek <sedat.dilek@...il.com>,
        Ming Lei <tom.leiming@...il.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [4.9-rc1] Build-time 2x slower

2016-10-18 19:19 GMT+02:00 Linus Torvalds <torvalds@...ux-foundation.org>:
> On Tue, Oct 18, 2016 at 9:49 AM, Jörg Otte <jrg.otte@...il.com> wrote:
>> On Tue, Oct 18, 2016 at 12:04 AM, Sedat Dilek <sedat.dilek@...il.com> 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