From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754724AbdJPRNq (ORCPT ); Mon, 16 Oct 2017 13:13:46 -0400 Received: from mail-it0-f54.google.com ([209.85.214.54]:48706 "EHLO mail-it0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753613AbdJPRNm (ORCPT ); Mon, 16 Oct 2017 13:13:42 -0400 X-Google-Smtp-Source: ABhQp+QjtZRXiMxa2Y4ABa/6ewREsg4aNuZ3bOwDWFMugXLhJjnGb2xW4n9z0OwPVc3we6rXj3bXNA== From: Douglas Anderson To: yamada.masahiro@socionext.com Cc: groeck@chromium.org, sjg@chromium.org, briannorris@chromium.org, mingo@kernel.org, Douglas Anderson , Matthias Kaehlcke , Marcin Nowakowski , Cao jin , Arnd Bergmann , Mark Charlebois , Kees Cook , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, Michal Marek , Josh Poimboeuf Subject: [PATCH v4 0/2] kbuild: Cache exploratory calls to the compiler Date: Mon, 16 Oct 2017 10:12:44 -0700 Message-Id: <20171016171246.15712-1-dianders@chromium.org> X-Mailer: git-send-email 2.15.0.rc0.271.g36b669edcc-goog Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Ingo Molnar also did some testing of this in his environment and found that an incremental build of his subsystem sped up from ~.44 seconds before to ~.15 seconds after. Clean builds also sped up by a marginal amount. :) Changes in v4: - Add a mkdir - Point to forward declaration commit by git hash Changes in v3: - Rule to prevent make from trying to generate the cache - Rule to clean .cache.mk - No more doc changes - Moved cache stuff below cc-cross-prefix - Removed duplicate documentation of try-run (oops) - Add Tested-by for Ingo and Guenter since v2 and v3 are very similar 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 Makefile | 5 +-- scripts/Kbuild.include | 90 ++++++++++++++++++++++++++++++++++++++++++-------- 2 files changed, 79 insertions(+), 16 deletions(-) -- 2.15.0.rc0.271.g36b669edcc-goog