On Tue, Oct 18, 2016 at 9:49 AM, Jörg Otte <jrg.o...@gmail.com> wrote:
> On Tue, Oct 18, 2016 at 12:04 AM, Sedat Dilek <sedat.di...@gmail.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

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.


Reply via email to