From: Douglas Anderson <dianders@chromium.org>
To: yamada.masahiro@socionext.com, mmarek@suse.com
Cc: groeck@chromium.org, sjg@chromium.org, briannorris@chromium.org,
Douglas Anderson <dianders@chromium.org>,
Marcin Nowakowski <marcin.nowakowski@imgtec.com>,
Matthias Kaehlcke <mka@chromium.org>,
Cao jin <caoj.fnst@cn.fujitsu.com>, Arnd Bergmann <arnd@arndb.de>,
Mark Charlebois <charlebm@gmail.com>,
linux-kbuild@vger.kernel.org, linux-doc@vger.kernel.org,
Jonathan Corbet <corbet@lwn.net>,
linux-kernel@vger.kernel.org,
James Hogan <james.hogan@imgtec.com>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Ingo Molnar <mingo@kernel.org>
Subject: [PATCH v2 0/2] kbuild: Cache exploratory calls to the compiler
Date: Wed, 4 Oct 2017 15:37:15 -0700 [thread overview]
Message-ID: <20171004223717.3010-1-dianders@chromium.org> (raw)
This two-patch series attempts to speed incremental builds of the
kernel up by a bit. How much of a speedup you get depends a lot on
your environment, specifically the speed of your workstation and how
fast it takes to invoke the compiler.
In the Chrome OS build environment you get a really big win. For an
incremental build (via emerge) I measured a speedup from ~1 minute to
~35 seconds. ...but Chrome OS calls the compiler through a number of
wrapper scripts and also calls the kernel make at least twice for an
emerge (during compile stage and install stage), so it's a bit of a
worst case.
Perhaps a more realistic measure of the speedup others might see is
running "time make help > /dev/null" outside of the Chrome OS build
environment on my system. When I do this I see that it took more than
1.0 seconds before and less than 0.2 seconds after. So presumably
this has the ability to shave ~0.8 seconds off an incremental build
for most folks out there. While 0.8 seconds savings isn't huge, it
does make incremental builds feel a lot snappier.
Caveats from v1 still copied here, though with Masahiro Yamada's
suggestions from v1 this is starting to feel a little more baked and
I've even dropped the RFC from it (though extra testing still
appreciated):
Please note that I make no illusions of being a Makefile expert nor do
I have any belief that I fully understand the Linux kernel build
system. Please take this patch series as the start of a discussion
about whether others feel like this type of speedup is worthwhile and
how to best accomplish it. Specific things to note:
- I'm happy to paint the bikeshed any color that maintainers want. If
you'd like the cache named differently, in a slightly different
format, or you want me to adjust the spacing / names of Makefile
stuff then please just let me know.
- If this is totally the wrong approach and you have a better idea
then let me know. If you want something that's super complicated to
explain then feel free to post a replacement patch and I'm happy to
test.
- This patch definitely needs extra testing. I've tested it on a very
limited build environment and it seems to be working fine, but I
could believe that with some weird compiler options or on certain
architectures you might need some extra escaping here and there.
Changes in v2:
- Abstract at a different level (like shell-cached) per Masahiro Yamada
- Include ld-version, which I missed the first time
Douglas Anderson (2):
kbuild: Add a cache for generated variables
kbuild: Cache a few more calls to the compiler
Documentation/kbuild/makefiles.txt | 21 +++++++++
Makefile | 4 +-
scripts/Kbuild.include | 90 ++++++++++++++++++++++++++++++++------
3 files changed, 99 insertions(+), 16 deletions(-)
--
2.14.2.920.gcf0c67979c-goog
next reply other threads:[~2017-10-04 22:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-04 22:37 Douglas Anderson [this message]
2017-10-04 22:37 ` [PATCH v2 1/2] kbuild: Add a cache for generated variables Douglas Anderson
2017-10-11 3:59 ` Masahiro Yamada
2017-10-11 16:20 ` Doug Anderson
2017-10-04 22:37 ` [PATCH v2 2/2] kbuild: Cache a few more calls to the compiler Douglas Anderson
2017-10-05 1:46 ` [PATCH v2 0/2] kbuild: Cache exploratory " Guenter Roeck
2017-10-05 7:52 ` Ingo Molnar
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=20171004223717.3010-1-dianders@chromium.org \
--to=dianders@chromium.org \
--cc=arnd@arndb.de \
--cc=briannorris@chromium.org \
--cc=caoj.fnst@cn.fujitsu.com \
--cc=charlebm@gmail.com \
--cc=corbet@lwn.net \
--cc=groeck@chromium.org \
--cc=james.hogan@imgtec.com \
--cc=jpoimboe@redhat.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcin.nowakowski@imgtec.com \
--cc=mingo@kernel.org \
--cc=mka@chromium.org \
--cc=mmarek@suse.com \
--cc=sjg@chromium.org \
--cc=yamada.masahiro@socionext.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.