public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
	openembedded-core <openembedded-core@lists.openembedded.org>
Cc: "markus.Lehtonen" <markus.Lehtonen@intel.com>
Subject: Re: Speed regression in the 4.8 kernel?
Date: Wed, 7 Sep 2016 07:56:55 -0400	[thread overview]
Message-ID: <86d45370-2472-5be2-d1c9-b0e44bd53291@windriver.com> (raw)
In-Reply-To: <1473240442.20226.111.camel@linuxfoundation.org>

On 2016-09-07 5:27 AM, Richard Purdie wrote:
> Hi Bruce,
>
> I deliberately spaced out the merges of various things so we could get
> performance measurements of the system as it happened. Unfortunately
> the 4.8 kernel appears to regress the kernel build time quite
> significantly:
>
> The raw data:
>
> ypperf02,master:9428b19a7dd1d265d9f3211004391abe33ea0224,uninative-1.3-414-g9428b19,1:01:32,4:21.16,1:00:32,2:10.86,0:16.19,0:11.21,0:01.20,5:34.73,26701616,6445160,1477762,5446116
> ypperf02,master:9428b19a7dd1d265d9f3211004391abe33ea0224,uninative-1.3-414-g9428b19,1:04:14,4:23.82,1:00:40,2:13.70,0:16.18,0:11.28,0:01.22,5:45.48,26697516,6445724,1478048,5446490
> ypperf02,master:b9d90ace005597ba35b59adcd8106a1c52e40c1a,uninative-1.3-438-gb9d90ac,1:03:16,7:22.13,1:02:46,2:16.60,0:16.32,0:11.04,0:01.21,5:42.11,30852876,10550952,1707255,5912282
> ypperf02,master:f7ca989ddc6d470429b547647d3fbaad83a982d9,uninative-1.3-446-gf7ca989,1:04:42,7:29.05,1:03:04,2:19.71,0:16.21,0:11.05,0:01.24,5:52.83,30845748,10551316,1707615,5912122
>
> which shows the time for "bitbake virtual/kernel -c cleansstate; time
> bitbake virtual/kernel" goes from 4:20 to 7:22. The disk footprint of
> the build went from 26GB to 30GB. The build with rm_work size went from
> 6.4GB to 10.5GB. The overall build time went up 2-3 minutes which looks
> like the increased kernel build time. The increased time may well be
> from the increased data being generated/processed.

Is it the actual compile itself ? What's the trick to actually get
individual task

For the disk footprint, I can check the refs in the tree and purge
anything that may be dangling. That being said, I can't do that to
the repository on the git server, so we may need someone that can
issue a git gc directly on the repository.

>
> We can't ship M3 with this much of a performance degradation and
> increased space usage :(. Any idea what changed?

Nope. I can only focus on one thing at a time. I was worried about
a functionally correct kernel (which I still am) and haven't looked
at anything in the peripheral yet.

If I can get individual task timings, I can look at it more.

I'm seeing significantly faster meta data phases, etc, so I'm interested
to know if this is purely in the build steps.

Cheers,

Bruce

>
> Cheers,
>
> Richard
>



  reply	other threads:[~2016-09-07 11:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-07  9:27 Speed regression in the 4.8 kernel? Richard Purdie
2016-09-07 11:56 ` Bruce Ashfield [this message]
2016-09-07 12:33   ` Markus Lehtonen
2016-09-07 12:44     ` Bruce Ashfield
2016-09-07 12:51       ` Markus Lehtonen
2016-09-07 14:00       ` Markus Lehtonen
2016-09-07 14:06         ` Bruce Ashfield
2016-09-07 14:15         ` Bruce Ashfield
2016-09-07 20:02           ` Bruce Ashfield

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86d45370-2472-5be2-d1c9-b0e44bd53291@windriver.com \
    --to=bruce.ashfield@windriver.com \
    --cc=markus.Lehtonen@intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox