From patchwork Fri Mar 8 21:25:23 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 10845443 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id B19FC1515 for ; Fri, 8 Mar 2019 21:25:43 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9E0B630209 for ; Fri, 8 Mar 2019 21:25:43 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9107330210; Fri, 8 Mar 2019 21:25:43 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 14EF130209 for ; Fri, 8 Mar 2019 21:25:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726388AbfCHVZm (ORCPT ); Fri, 8 Mar 2019 16:25:42 -0500 Received: from mail-pg1-f196.google.com ([209.85.215.196]:34238 "EHLO mail-pg1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726332AbfCHVZm (ORCPT ); Fri, 8 Mar 2019 16:25:42 -0500 Received: by mail-pg1-f196.google.com with SMTP id i130so15114929pgd.1 for ; Fri, 08 Mar 2019 13:25:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=j9+MHBMZ3wKobKUk7FRnddyFnv2NMsRUrYl0hUzBrNw=; b=ZR0GBvuIOiATShpHvYI3WFMaJWO9p7G4wn2iIIGtKRPQIRFDF4agB3AzzxAm0iWta9 a82kZPPPbsBPcFZSUAc7jr0+zHfU2gbfutpUk+m5h9ouM3AeG/2LZA+97S8VkIqllNfu YLFOokZ1PmItLamI8rQIWddlZM6BGRea53ACA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=j9+MHBMZ3wKobKUk7FRnddyFnv2NMsRUrYl0hUzBrNw=; b=kpGr2NLQs5P54Nsn7Y18H3dlyEzeiQ5wnSe2zuFMR0OewwS4JfdCBHEpJ+IgxQ+E8y mTsGGWi+J6URUSksQ3RMp+HJQ+tnIomLjQQFxho4UScs09tCdP+Dyan8VSgnZTuT/n3T GfVvLEZ6ZmcP3Z5r+Kake2UQipETphEbKmy7JpnRmB0f9B/znN8tweprmeOgBAw94psF B+RfC4dRJxamW33KEXAfwbXeqfPZRjjQnUIpd/IO5X3mV5cOyBImLQ2XUfaQo53wcWyw aRwjDDnyplWc9Bn1/Ldhlw0o0ibW7q21w0DGyPmM3OpvgUU4PguZcSvYgnTuVn3W7H0b 9OAw== X-Gm-Message-State: APjAAAVgAXAXHVzuekDnFhM6+VJszeLT2rrDpsXUXK5wljPn5OFJztZW WKotQvgjU3aFqA2MNKu0fxVgKQ== X-Google-Smtp-Source: APXvYqyrFsuPI+J/rSJr/qbj786t/px+jLZD97RqjPyY5Wg0jgAoPHArlYM5mL39NCwPKklgZ79hmA== X-Received: by 2002:a62:70c9:: with SMTP id l192mr20670125pfc.207.1552080341451; Fri, 08 Mar 2019 13:25:41 -0800 (PST) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:1:24fa:e766:52c9:e3b2]) by smtp.gmail.com with ESMTPSA id h3sm9684639pgv.38.2019.03.08.13.25.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Mar 2019 13:25:40 -0800 (PST) From: Douglas Anderson To: Masahiro Yamada , Michal Marek Cc: groeck@chromium.org, briannorris@chromium.org, swboyd@chromium.org, Douglas Anderson , linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org Subject: [PATCH] kbuild: Speed up install, modules_install and kernelrelease Date: Fri, 8 Mar 2019 13:25:23 -0800 Message-Id: <20190308212524.121126-1-dianders@chromium.org> X-Mailer: git-send-email 2.21.0.360.g471c308f928-goog MIME-Version: 1.0 Sender: linux-kbuild-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP As per the description of the old commit 3298b690b21c ("kbuild: Add a cache for generated variables"), calling the C compiler lots of times during the parsing stage of the Makefile can be a little slow. If you happen to have a C compiler whose fork/exec time isn't optimized (perhaps it was linked dynamically, or perhaps it's called through several wrappers, or ...) then this can be more than a little slow, it can be very slow. The above slowness was addressed with the old Makefile cache, but the cache was reverted in commit e08d6de4e532 ("kbuild: remove kbuild cache"). That commit indicated that we expected to get the speed gains back because "the result of compiler tests will be naturally cached in the .config file", but as of the latest mainline there are still lots of direct calls to the C compiler that happen in the Makefile parsing stage. Perhaps we could try re-introducing the Makefile cache and fix the problems it was causing, but this patch codes up another solution that gets some of the speed gains back, perhaps with less complexity. Specifically I observed that by timing the parsing stage of the Makefile by adding statements like this to the beginning and end of the Makefile: ZZZ := $(shell echo "$$(date '+%T.%N'): ..." >> /tmp/timing.txt) ...that three targets were spending 3 seconds each parsing the Makefile in my environment (building a Chrome OS kernel with clang) when it felt like they ought to be quick. These were: install, modules_install and kernelrelease I saw timings that looked like: 09:23:08.903204451: Parsing Makefile, goals: install 09:23:11.960515772: Done parsing Makefile, goals: install Given that the kbuild system doesn't sync the config for any of these options I believe it is safe to say that it can't compile any code. Thus if we can avoid the C compiler invocation here we'll save time. The simplest way to accomplish this is to neuter all the calls to the compiler by stubbing them out. After doing so (AKA applying this change) the same timing looks like: 09:28:04.929252271: Parsing Makefile, goals: install 09:28:05.107468449: Done parsing Makefile, goals: install During an incremental kernel build/install on Chrome OS we call install once, modules_install twice (once to keep unstripped), and kernelrelease once. Thus this saves ~12 seconds on an incremental kernel build/install. With my current setup, this brings it from ~40 seconds to ~28 seconds. Re-introducing the Makefile cache would likely save us an extra ~3 seconds since we'd avoid the parsing in the compile stage. Signed-off-by: Douglas Anderson --- Makefile | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/Makefile b/Makefile index f070e0d65186..5f7532d9be65 100644 --- a/Makefile +++ b/Makefile @@ -304,6 +304,20 @@ else scripts/Kbuild.include: ; include scripts/Kbuild.include +# If we can't sync the config then we know we can't compile code. +# Replace the slow option-testing commands with stubs to significantly +# speed up the Makefile parsing stage of the build. +ifeq ($(may-sync-config),0) + ar-option := + as-option := + cc-disable-warning := + cc-ifversion := + cc-ldoption := + cc-option := + cc-option-yn := n + ld-option := +endif + # Read KERNELRELEASE from include/config/kernel.release (if it exists) KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null) KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)