From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: openembedded-core <openembedded-core@lists.openembedded.org>
Cc: "Hart, Darren" <darren.hart@intel.com>
Subject: linux-yocto task performance numbers
Date: Sun, 22 Feb 2015 13:04:11 +0000 [thread overview]
Message-ID: <1424610251.11836.74.camel@linuxfoundation.org> (raw)
As people know, I've been looking at performance a little, one of the
benchmarks is how long the kernel takes to build. I dumped out the task
performance data from buildstats for a linux-yocto build (nothing else
running):
do_fetch: Elapsed time: 0.04 seconds
do_unpack: Elapsed time: 1.61 seconds
do_kernel_checkout: Elapsed time: 4.39 seconds
do_validate_branches: Elapsed time: 0.47 seconds
do_patch: Elapsed time: 57.77 seconds
do_kernel_configme: Elapsed time: 44.92 seconds
do_kernel_configcheck: Elapsed time: 8.94 seconds
do_configure: Elapsed time: 0.60 seconds
do_compile: Elapsed time: 72.95 seconds
do_compile_kernelmodules: Elapsed time: 34.84 seconds
do_populate_lic: Elapsed time: 0.14 seconds
do_strip: Elapsed time: 0.03 seconds
do_uboot_mkimage: Elapsed time: 0.03 seconds
do_install: Elapsed time: 1.87 seconds
do_populate_sysroot: Elapsed time: 0.16 seconds
do_shared_workdir: Elapsed time: 0.05 seconds
do_sizecheck: Elapsed time: 0.03 seconds
do_bundle_initramfs: Elapsed time: 0.03 seconds
do_kernel_link_vmlinux: Elapsed time: 0.03 seconds
do_deploy: Elapsed time: 13.17 seconds
do_package: Elapsed time: 31.54 seconds
do_packagedata: Elapsed time: 0.59 seconds
do_package_qa: Elapsed time: 5.30 seconds
do_package_write_ipk: Elapsed time: 83.24 seconds
do_package_write_rpm: Elapsed time: 44.58 seconds
The "core" was getting blamed for a lot of the build time. As can be
seen, the "core" isn't taking that much time now, apart from the fact
that ipk packaging seems to be taking twice the time of rpm which needs
looking into.
Some tasks like the compile tasks are understandable and likely
minimised by upstream work already.
The other tasks which as consuming a disproportionate amount of time are
kernel_configme and patch, I believe we need to look into those a little
further too. To put it into context, should the kernel compile be at the
same order of magnitude as the patch and configure?
Cheers,
Richard
next reply other threads:[~2015-02-22 13:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-22 13:04 Richard Purdie [this message]
2015-02-22 14:05 ` linux-yocto task performance numbers Bruce Ashfield
2015-02-23 5:13 ` Bruce Ashfield
2015-02-23 10:08 ` Richard Purdie
2015-02-23 10:22 ` Richard Purdie
2015-02-23 13:14 ` Bruce Ashfield
2015-02-23 16:25 ` Hart, Darren
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=1424610251.11836.74.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=darren.hart@intel.com \
--cc=openembedded-core@lists.openembedded.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