Message ID | 20230406190030.968972-9-allenwebb@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1240400vqo; Thu, 6 Apr 2023 12:03:56 -0700 (PDT) X-Google-Smtp-Source: AKy350bQiXxiK0otVbQzOsv2yUyeKegTSgQ9d/CPsuVpyIltGH2ymm5VtHCVdrtyYL6EpTKW/I4a X-Received: by 2002:a17:906:d54b:b0:920:7827:302 with SMTP id cr11-20020a170906d54b00b0092078270302mr7298217ejc.18.1680807836300; Thu, 06 Apr 2023 12:03:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680807836; cv=none; d=google.com; s=arc-20160816; b=Tb+APQfGn3QGiImaD/3ykgghLbrx/RyZQJKNZWVgjkhXeLd02yP6giJejt/NiPsJPb uoKXIGEfND8/5bdU2OzLdWSz+yzt55nwVnvGsRAM454Yg16y6vni4PVNb8FCvrvBcKam AtnhWG2BflHjbKOgIFYngLP+VJNrPouNLogDu5drBtEjujGMXbtNAKcbZwfjPT2o05Ra +DkJbTyUtXkzjz5CtHayArWGzWpnHbeO22AbzDkC8lK8jofN/m5cO5o/79T2F1TY813G FsxzVfL7zg2dLsAagmJMO7699sDMMuCxxEOT6yAUwJNy/ToN/LgG5/qsHgKgGtk7FsKk pPLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:dkim-signature; bh=EIFZuvNlh3Q7f5viDBmDdFqHrpvMkDaR3sC9sXOJCEg=; b=lUc24GUaCVfc4jlZuE1hQu/nYdug2QbBKUbG0fj4+mx0N0pQKKTk9i4frHtFusj9FA rSaTrXtScEVAw89GbMtIVmSn16DKIeIBW/C3CgPWQo1S3bwkDEMt+jPtBa/2aLbHTgx/ UodJMBSpzmOYMoCsgH6phiwisjajQrxdICBt5qHe1oUM8IF0+PlgRo6t5zW1tufdycw5 DQPunkmoY7zqxI0lfciT1JdAW9sKLB8PERPSwbxp9vgZcBABpc1H2q3MzAKc3T2kpg6V tQasvjN8N3WQYvCtSztRCBaxXks1ZI7Pulx0w7qIq8Z+3dA8yxN6QkNAlg+zzVzbLC72 vfZw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=r6Dgw36L; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v15-20020a17090610cf00b0093e7ed91726si1947150ejv.480.2023.04.06.12.03.31; Thu, 06 Apr 2023 12:03:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=r6Dgw36L; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240517AbjDFTBv (ORCPT <rfc822;a1648639935@gmail.com> + 99 others); Thu, 6 Apr 2023 15:01:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55400 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240422AbjDFTBa (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 6 Apr 2023 15:01:30 -0400 Received: from mail-il1-x14a.google.com (mail-il1-x14a.google.com [IPv6:2607:f8b0:4864:20::14a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 599929039 for <linux-kernel@vger.kernel.org>; Thu, 6 Apr 2023 12:01:06 -0700 (PDT) Received: by mail-il1-x14a.google.com with SMTP id s1-20020a92ae01000000b0032637be81d1so15770465ilh.4 for <linux-kernel@vger.kernel.org>; Thu, 06 Apr 2023 12:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680807665; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=EIFZuvNlh3Q7f5viDBmDdFqHrpvMkDaR3sC9sXOJCEg=; b=r6Dgw36L4ye+f7TRQYGeV5tzr0btpwq3zzgs/UuXhg7VhxHkEGdn4IEj/h2PQMM8C7 9XrmV58b2OYGBa/Itz+04VD1lyNfP8oKVgBL+a+JqxD9bgvLCoGGT9xlOS7M7FSZhlrL dgPrDoQF1NMokITcEqaqE16eLq+/TyrGqoh7gwe5XUJYnNmAwK+1UyWGWYmy5FrIUyET RBrF9++/dM7QoNSpDAic5FyiBVC0USYGzK5MLgC687r/qXuqx0qG4J/VlJlQEiwErT5K pXhpKWhcW9txjXhgoS8Wh4mQInW++2qbyZT76CeylXl4fLCs7gG2hexuiYdjLRP04I53 0URw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680807665; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=EIFZuvNlh3Q7f5viDBmDdFqHrpvMkDaR3sC9sXOJCEg=; b=SIqAvB+EmJyYJoLNVPMPNxJPrrHfnKMVo8oGjfaYR7ltMdpzbRjmYO3JyDhyTe4ykZ B7bGSavjJEtTrO+exY0Min4yuf0M/0Cca5Kw6G6u+/TFmDZo1lEFa+zguMKkg3PExBnY IytFY/6nd6CxiLjnh3lOwP0dC+5gEC3vjgxm619AYUZU61+1DRUROUC/M95X5IcQyHE7 oXtty7gcjZ0xWVpDurAmYtIT+SRjUPALtQvb4O3UBjhBCapax9cg/fhY6kpoamhnVApO l4qvFYQ9kq7S+rItJ7mFSmJtfc5n30gmJBnkmir/mzk7QPKy/8l5hi/IZ80e6k+mgw4+ eHiA== X-Gm-Message-State: AAQBX9cvLjgjgLT39Bcwtezk0LAPwuvokdUS3IdCAQFrcU8CPCzJe97y M2Z23DwFMYJgqEIIopTeSrQ2rftD+GHVcKo= X-Received: from allenwebb.c.googlers.com ([fda3:e722:ac3:cc00:2b:ff92:c0a8:12e8]) (user=allenwebb job=sendgmr) by 2002:a05:6e02:f44:b0:310:9afc:aa6 with SMTP id y4-20020a056e020f4400b003109afc0aa6mr6249545ilj.0.1680807665734; Thu, 06 Apr 2023 12:01:05 -0700 (PDT) Date: Thu, 6 Apr 2023 14:00:27 -0500 In-Reply-To: <20230406190030.968972-1-allenwebb@google.com> Mime-Version: 1.0 References: <20221219204619.2205248-1-allenwebb@google.com> <20230406190030.968972-1-allenwebb@google.com> X-Mailer: git-send-email 2.40.0.577.gac1e443424-goog Message-ID: <20230406190030.968972-9-allenwebb@google.com> Subject: [PATCH v10 08/11] build: Add modules.builtin.alias From: Allen Webb <allenwebb@google.com> To: "linux-modules@vger.kernel.org" <linux-modules@vger.kernel.org>, "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Cc: gregkh@linuxfoundation.org, mcgrof@kernel.org, christophe.leroy@csgroup.eu, nick.alcock@oracle.com, Allen Webb <allenwebb@google.com> Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.7 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1752410806438307616?= X-GMAIL-MSGID: =?utf-8?q?1762454758136396709?= |
Series |
Generate modules.builtin.alias from match ids
|
|
Commit Message
Allen Webb
April 6, 2023, 7 p.m. UTC
Generate modules.builtin.alias using modpost and install it with the
modules.
Signed-off-by: Allen Webb <allenwebb@google.com>
---
.gitignore | 1 +
Makefile | 1 +
scripts/Makefile.modpost | 15 +++++++++++++++
3 files changed, 17 insertions(+)
Comments
On Thu, Apr 06, 2023 at 02:00:27PM -0500, Allen Webb wrote: > Generate modules.builtin.alias using modpost and install it with the > modules. Why? This is probably one of the more important commits and the commit log is pretty slim. > Signed-off-by: Allen Webb <allenwebb@google.com> > --- > .gitignore | 1 + > Makefile | 1 + > scripts/Makefile.modpost | 15 +++++++++++++++ > 3 files changed, 17 insertions(+) > > diff --git a/.gitignore b/.gitignore > index 13a7f08a3d73..ddaa622bddac 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -71,6 +71,7 @@ modules.order > /System.map > /Module.markers > /modules.builtin > +/modules.builtin.alias > /modules.builtin.modinfo > /modules.nsdeps > > diff --git a/Makefile b/Makefile > index a2c310df2145..43dcc1ea5fcf 100644 > --- a/Makefile > +++ b/Makefile > @@ -1578,6 +1578,7 @@ __modinst_pre: > fi > @sed 's:^\(.*\)\.o$$:kernel/\1.ko:' modules.order > $(MODLIB)/modules.order > @cp -f modules.builtin $(MODLIB)/ > + @cp -f modules.builtin.alias $(MODLIB)/ > @cp -f $(objtree)/modules.builtin.modinfo $(MODLIB)/ > > endif # CONFIG_MODULES > diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost > index 0980c58d8afc..e3ecc17a7a19 100644 > --- a/scripts/Makefile.modpost > +++ b/scripts/Makefile.modpost > @@ -15,6 +15,7 @@ > # 2) modpost is then used to > # 3) create one <module>.mod.c file per module > # 4) create one Module.symvers file with CRC for all exported symbols > +# 5) create modules.builtin.alias the aliases for built-in modules Does everyone want that file? > # Step 3 is used to place certain information in the module's ELF > # section, including information such as: > @@ -63,6 +64,20 @@ modpost-args += -T $(MODORDER) > modpost-deps += $(MODORDER) > endif > > +ifneq ($(wildcard vmlinux.o),) > +output-builtin.alias := modules.builtin.alias > +modpost-args += -b .modules.builtin.alias.in > +.modules.builtin.alias.in: $(output-symdump) > + @# Building $(output-symdump) generates .modules.builtin.alias.in as a > + @# side effect. > + @[ -e $@ ] || $(MODPOST) -b .modules.builtin.alias.in vmlinux.o Does using -b create a delay in builds ? What is the effect on build time on a typical 4-core or 8-core build? Does everyone want it? Should we add a new option which lets people decide if they want this at build time or not? Luis > + > +$(output-builtin.alias): .modules.builtin.alias.in > + sort -o $@ $^ > + > +__modpost: $(output-builtin.alias) > +endif > + > ifeq ($(KBUILD_EXTMOD),) > > # Generate the list of in-tree objects in vmlinux > -- > 2.39.2 >
I finally got a chance to go through the comments and work on a follow-up to this series, but it probably makes sense to get this sorted ahead of the follow-up (if possible). On Wed, May 24, 2023 at 2:02 AM Luis Chamberlain <mcgrof@kernel.org> wrote: > > On Thu, Apr 06, 2023 at 02:00:27PM -0500, Allen Webb wrote: > > Generate modules.builtin.alias using modpost and install it with the > > modules. > > Why? This is probably one of the more important commits and the > commit log is pretty slim. > > > Signed-off-by: Allen Webb <allenwebb@google.com> > > --- > > .gitignore | 1 + > > Makefile | 1 + > > scripts/Makefile.modpost | 15 +++++++++++++++ > > 3 files changed, 17 insertions(+) > > > > diff --git a/.gitignore b/.gitignore > > index 13a7f08a3d73..ddaa622bddac 100644 > > --- a/.gitignore > > +++ b/.gitignore > > @@ -71,6 +71,7 @@ modules.order > > /System.map > > /Module.markers > > /modules.builtin > > +/modules.builtin.alias > > /modules.builtin.modinfo > > /modules.nsdeps > > > > diff --git a/Makefile b/Makefile > > index a2c310df2145..43dcc1ea5fcf 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1578,6 +1578,7 @@ __modinst_pre: > > fi > > @sed 's:^\(.*\)\.o$$:kernel/\1.ko:' modules.order > $(MODLIB)/modules.order > > @cp -f modules.builtin $(MODLIB)/ > > + @cp -f modules.builtin.alias $(MODLIB)/ > > @cp -f $(objtree)/modules.builtin.modinfo $(MODLIB)/ > > > > endif # CONFIG_MODULES > > diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost > > index 0980c58d8afc..e3ecc17a7a19 100644 > > --- a/scripts/Makefile.modpost > > +++ b/scripts/Makefile.modpost > > @@ -15,6 +15,7 @@ > > # 2) modpost is then used to > > # 3) create one <module>.mod.c file per module > > # 4) create one Module.symvers file with CRC for all exported symbols > > +# 5) create modules.builtin.alias the aliases for built-in modules > > Does everyone want that file? Not everyone needs it so we could exclude it, but the cost of adding it isn't that high. I am fine with putting it behind a config, though we would need to decide whether to have it default on/off. > > > # Step 3 is used to place certain information in the module's ELF > > # section, including information such as: > > @@ -63,6 +64,20 @@ modpost-args += -T $(MODORDER) > > modpost-deps += $(MODORDER) > > endif > > > > +ifneq ($(wildcard vmlinux.o),) > > +output-builtin.alias := modules.builtin.alias > > +modpost-args += -b .modules.builtin.alias.in > > +.modules.builtin.alias.in: $(output-symdump) > > + @# Building $(output-symdump) generates .modules.builtin.alias.in as a > > + @# side effect. > > + @[ -e $@ ] || $(MODPOST) -b .modules.builtin.alias.in vmlinux.o > > Does using -b create a delay in builds ? What is the effect on build > time on a typical 4-core or 8-core build? Does everyone want it? Here is some data I collected related to build time and memory usage impact: Without builtin.alias: TIME="real %e\nuser %U\nsys %S\nres-max %M" time scripts/mod/modpost -E -o Module.symvers -T modules.order ERROR: modpost: "__x86_return_thunk" [arch/x86/crypto/chacha-x86_64.ko] undefined! ERROR: modpost: "kernel_fpu_end" [arch/x86/crypto/chacha-x86_64.ko] undefined! ERROR: modpost: "hchacha_block_generic" [arch/x86/crypto/chacha-x86_64.ko] undefined! ERROR: modpost: "boot_cpu_data" [arch/x86/crypto/chacha-x86_64.ko] undefined! ERROR: modpost: "static_key_enable" [arch/x86/crypto/chacha-x86_64.ko] undefined! ERROR: modpost: "cpu_has_xfeatures" [arch/x86/crypto/chacha-x86_64.ko] undefined! ERROR: modpost: "crypto_register_skciphers" [arch/x86/crypto/chacha-x86_64.ko] undefined! ERROR: modpost: "crypto_unregister_skciphers" [arch/x86/crypto/chacha-x86_64.ko] undefined! ERROR: modpost: "__stack_chk_fail" [arch/x86/crypto/chacha-x86_64.ko] undefined! ERROR: modpost: "memset" [arch/x86/crypto/chacha-x86_64.ko] undefined! WARNING: modpost: suppressed 17432 unresolved symbol warnings because there were too many) Command exited with non-zero status 1 real 0.44 user 0.43 sys 0.01 res-max 4896 With builtin.alias: TIME="real %e\nuser %U\nsys %S\nres-max %M" time scripts/mod/modpost -E -o Module.symvers -T modules.order -b .modules.builtin.alias.in vmlinux.o real 1.43 user 1.38 sys 0.05 res-max 51920 Notice that modpost only uses a single core, so multicore isn't really as much of a factor here. While it more than triples the time required for the modpost operation the difference is only about one second of CPU time. The memory usage is much larger when generating modules.builtin.alias because of the size of vmlinux.o. My biggest performance related concern is actually the size difference of vmlinux caused by the modules.h changes, but it looks like that is negligible (24KiB): Without builtin.alias: du vmlinux.o 663048 vmlinux.o With builtin.alias: du vmlinux.o 663072 vmlinux.o > > Should we add a new option which lets people decide if they want this > at build time or not? I don't feel strongly that there should or should not be a config for this. On the side for a config the extra second of CPU time and space taken up by the modules.builtin.alias file would add up across all the builds and machines, so removing it where it isn't used would help mitigate that. On the flip side if it isn't used widely enough, it is more likely that breakages are missed until someone who actually uses it notices. Please let me know if you feel strongly either way given the data. Thanks, Allen > > Luis > > > + > > +$(output-builtin.alias): .modules.builtin.alias.in > > + sort -o $@ $^ > > + > > +__modpost: $(output-builtin.alias) > > +endif > > + > > ifeq ($(KBUILD_EXTMOD),) > > > > # Generate the list of in-tree objects in vmlinux > > -- > > 2.39.2 > >
Please cc Alexander and Alessandro in future patch series as well, as they could likley be interested in your work too. On Wed, Jul 19, 2023 at 02:51:48PM -0500, Allen Webb wrote: > I finally got a chance to go through the comments and work on a > follow-up to this series, but it probably makes sense to get this > sorted ahead of the follow-up (if possible). > > On Wed, May 24, 2023 at 2:02 AM Luis Chamberlain <mcgrof@kernel.org> wrote: > > > > On Thu, Apr 06, 2023 at 02:00:27PM -0500, Allen Webb wrote: > > > Generate modules.builtin.alias using modpost and install it with the > > > modules. > > > > Why? This is probably one of the more important commits and the > > commit log is pretty slim. > > > > > Signed-off-by: Allen Webb <allenwebb@google.com> > > > --- > > > .gitignore | 1 + > > > Makefile | 1 + > > > scripts/Makefile.modpost | 15 +++++++++++++++ > > > 3 files changed, 17 insertions(+) > > > > > > diff --git a/.gitignore b/.gitignore > > > index 13a7f08a3d73..ddaa622bddac 100644 > > > --- a/.gitignore > > > +++ b/.gitignore > > > @@ -71,6 +71,7 @@ modules.order > > > /System.map > > > /Module.markers > > > /modules.builtin > > > +/modules.builtin.alias > > > /modules.builtin.modinfo > > > /modules.nsdeps > > > > > > diff --git a/Makefile b/Makefile > > > index a2c310df2145..43dcc1ea5fcf 100644 > > > --- a/Makefile > > > +++ b/Makefile > > > @@ -1578,6 +1578,7 @@ __modinst_pre: > > > fi > > > @sed 's:^\(.*\)\.o$$:kernel/\1.ko:' modules.order > $(MODLIB)/modules.order > > > @cp -f modules.builtin $(MODLIB)/ > > > + @cp -f modules.builtin.alias $(MODLIB)/ > > > @cp -f $(objtree)/modules.builtin.modinfo $(MODLIB)/ > > > > > > endif # CONFIG_MODULES > > > diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost > > > index 0980c58d8afc..e3ecc17a7a19 100644 > > > --- a/scripts/Makefile.modpost > > > +++ b/scripts/Makefile.modpost > > > @@ -15,6 +15,7 @@ > > > # 2) modpost is then used to > > > # 3) create one <module>.mod.c file per module > > > # 4) create one Module.symvers file with CRC for all exported symbols > > > +# 5) create modules.builtin.alias the aliases for built-in modules > > > > Does everyone want that file? > > Not everyone needs it so we could exclude it, but the cost of adding > it isn't that high. I am fine with putting it behind a config, though > we would need to decide whether to have it default on/off. We didn't know the cost until I asked, it was the point of asking. Perhaps Nick, Alessandro or Alexander could use it too later. > > > # Step 3 is used to place certain information in the module's ELF > > > # section, including information such as: > > > @@ -63,6 +64,20 @@ modpost-args += -T $(MODORDER) > > > modpost-deps += $(MODORDER) > > > endif > > > > > > +ifneq ($(wildcard vmlinux.o),) > > > +output-builtin.alias := modules.builtin.alias > > > +modpost-args += -b .modules.builtin.alias.in > > > +.modules.builtin.alias.in: $(output-symdump) > > > + @# Building $(output-symdump) generates .modules.builtin.alias.in as a > > > + @# side effect. > > > + @[ -e $@ ] || $(MODPOST) -b .modules.builtin.alias.in vmlinux.o > > > > Does using -b create a delay in builds ? What is the effect on build > > time on a typical 4-core or 8-core build? Does everyone want it? > > Here is some data I collected related to build time and memory usage impact: > > Without builtin.alias: > TIME="real %e\nuser %U\nsys %S\nres-max %M" time scripts/mod/modpost > -E -o Module.symvers -T modules.order > ERROR: modpost: "__x86_return_thunk" > [arch/x86/crypto/chacha-x86_64.ko] undefined! > ERROR: modpost: "kernel_fpu_end" [arch/x86/crypto/chacha-x86_64.ko] undefined! > ERROR: modpost: "hchacha_block_generic" > [arch/x86/crypto/chacha-x86_64.ko] undefined! > ERROR: modpost: "boot_cpu_data" [arch/x86/crypto/chacha-x86_64.ko] undefined! > ERROR: modpost: "static_key_enable" [arch/x86/crypto/chacha-x86_64.ko] > undefined! > ERROR: modpost: "cpu_has_xfeatures" [arch/x86/crypto/chacha-x86_64.ko] > undefined! > ERROR: modpost: "crypto_register_skciphers" > [arch/x86/crypto/chacha-x86_64.ko] undefined! > ERROR: modpost: "crypto_unregister_skciphers" > [arch/x86/crypto/chacha-x86_64.ko] undefined! > ERROR: modpost: "__stack_chk_fail" [arch/x86/crypto/chacha-x86_64.ko] undefined! > ERROR: modpost: "memset" [arch/x86/crypto/chacha-x86_64.ko] undefined! > WARNING: modpost: suppressed 17432 unresolved symbol warnings because > there were too many) > Command exited with non-zero status 1 > real 0.44 > user 0.43 > sys 0.01 > res-max 4896 > > With builtin.alias: > TIME="real %e\nuser %U\nsys %S\nres-max %M" time scripts/mod/modpost > -E -o Module.symvers -T modules.order -b .modules.builtin.alias.in > vmlinux.o > real 1.43 > user 1.38 > sys 0.05 > res-max 51920 > > Notice that modpost only uses a single core, so multicore isn't really > as much of a factor here. While it more than triples the time required > for the modpost operation the difference is only about one second of > CPU time. The memory usage is much larger when generating > modules.builtin.alias because of the size of vmlinux.o. The modpost impact time of about 1 second for a type of config you used should be described in your commit log and or kconfig entry to enable this. > My biggest performance related concern is actually the size difference > of vmlinux caused by the modules.h changes, but it looks like that is > negligible (24KiB): And this size too. 24 KiB is not that small, so I'd prefer we kconfig'ize it for now and have those who need it to select it. If we later all want it, we can default to yes but for now default to no. The default today by kconfig is to no so an empty default is fine. > Without builtin.alias: > du vmlinux.o > 663048 vmlinux.o > > With builtin.alias: > du vmlinux.o > 663072 vmlinux.o What type of configuration was used? allyesconfig? > > > > Should we add a new option which lets people decide if they want this > > at build time or not? > > I don't feel strongly that there should or should not be a config for > this. On the side for a config the extra second of CPU time and space > taken up by the modules.builtin.alias file would add up across all the > builds and machines, so removing it where it isn't used would help > mitigate that. On the flip side if it isn't used widely enough, it is > more likely that breakages are missed until someone who actually uses > it notices. > > Please let me know if you feel strongly either way given the data. For now I'd prefer a kconfig option, it's easy to default to y later, but saving 64 KiB seems like a desirable thing for some folks. Luis
diff --git a/.gitignore b/.gitignore index 13a7f08a3d73..ddaa622bddac 100644 --- a/.gitignore +++ b/.gitignore @@ -71,6 +71,7 @@ modules.order /System.map /Module.markers /modules.builtin +/modules.builtin.alias /modules.builtin.modinfo /modules.nsdeps diff --git a/Makefile b/Makefile index a2c310df2145..43dcc1ea5fcf 100644 --- a/Makefile +++ b/Makefile @@ -1578,6 +1578,7 @@ __modinst_pre: fi @sed 's:^\(.*\)\.o$$:kernel/\1.ko:' modules.order > $(MODLIB)/modules.order @cp -f modules.builtin $(MODLIB)/ + @cp -f modules.builtin.alias $(MODLIB)/ @cp -f $(objtree)/modules.builtin.modinfo $(MODLIB)/ endif # CONFIG_MODULES diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost index 0980c58d8afc..e3ecc17a7a19 100644 --- a/scripts/Makefile.modpost +++ b/scripts/Makefile.modpost @@ -15,6 +15,7 @@ # 2) modpost is then used to # 3) create one <module>.mod.c file per module # 4) create one Module.symvers file with CRC for all exported symbols +# 5) create modules.builtin.alias the aliases for built-in modules # Step 3 is used to place certain information in the module's ELF # section, including information such as: @@ -63,6 +64,20 @@ modpost-args += -T $(MODORDER) modpost-deps += $(MODORDER) endif +ifneq ($(wildcard vmlinux.o),) +output-builtin.alias := modules.builtin.alias +modpost-args += -b .modules.builtin.alias.in +.modules.builtin.alias.in: $(output-symdump) + @# Building $(output-symdump) generates .modules.builtin.alias.in as a + @# side effect. + @[ -e $@ ] || $(MODPOST) -b .modules.builtin.alias.in vmlinux.o + +$(output-builtin.alias): .modules.builtin.alias.in + sort -o $@ $^ + +__modpost: $(output-builtin.alias) +endif + ifeq ($(KBUILD_EXTMOD),) # Generate the list of in-tree objects in vmlinux