Received: by 2002:a05:6358:7058:b0:131:369:b2a3 with SMTP id 24csp8679855rwp; Wed, 19 Jul 2023 13:39:00 -0700 (PDT) X-Google-Smtp-Source: APBJJlGKhu7Ih1u+of5zkYXngiFObgRXnJ7HRpuxBMkUa7UGR7uCzv/cqRCbhqr5ig5msiLiYEGe X-Received: by 2002:a17:906:b003:b0:992:6656:4043 with SMTP id v3-20020a170906b00300b0099266564043mr397643ejy.53.1689799139962; Wed, 19 Jul 2023 13:38:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689799139; cv=none; d=google.com; s=arc-20160816; b=pu/nwoHatk1nznW6urOJ/2We5GQICSUqLG+be5JX+JBl5Gh6jNDPnykowSyx5GxsnV pLGHXS+T2RsCh8b4/WmSCCxrDhwp1rTqqGVxGoWJ57LNwXvu66N30I+I4jdr7Zl9Wndp EXyVJ2pvqAwlXfw4fAQFpwVHqAgqrzhNucYHyXaBO/VGz9mO0nNhqavHlqQvi2fqItd3 xmsnUW0gMSfolmAn5lkpmkTPdzZEf1T90hubFYDEL/Hydnpws+L4D0TVcWQYkiJUN9t8 SSVjeRLf4XGX8LvQxWmpA0879ea6dIM2RoGvBf2CsgU9lN+MUD2NnrYu/Zx6764HUjko I4MA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=JYOwNntA5WE6xe24NJ4pZv26m9x1H9FPfyiIwBhTOwY=; fh=ItUhggka0f340GPkFhUMAak10DC8Gud3D2P6tac9nfQ=; b=JY1PTco5B2HPpS6qpTDH3+NjFWP+9KU37UjeIhlyFxL0SGTtrI/HW71q9aMwS7L4iR Qx+mOT9+CMtskUFiGs7ei4TbBhYwWAcvXKaT6ixGUtDCLJyVNpIP9IhVedvLQohlg8pQ cjXCjGc1FXvCsWNrpSAZ/5kO79FzjLO9xZCj8Q4/WandVjLM2cM6pwsDe3LHp7bbq9w0 bgFECx7Ca9/EmwVRnWyeF436QIHMN263W5cssV+hblpBW/T3cSyEob2VUfm1CQzP472O hsmsg7pLBWGzNe+DjOXT9RO+Sbuoo61Nec77rrs7xnZVDT2C5C5axoejcJO5I3DlzPDr pyQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=YLruMY8r; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k2-20020a17090627c200b00993a9a951f9si3103495ejc.28.2023.07.19.13.38.35; Wed, 19 Jul 2023 13:38:59 -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=20221208 header.b=YLruMY8r; 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 S231241AbjGSTwE (ORCPT + 99 others); Wed, 19 Jul 2023 15:52:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40398 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229853AbjGSTwD (ORCPT ); Wed, 19 Jul 2023 15:52:03 -0400 Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C03371FCD for ; Wed, 19 Jul 2023 12:52:00 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id ada2fe7eead31-440ad406bc8so19632137.3 for ; Wed, 19 Jul 2023 12:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1689796320; x=1690401120; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JYOwNntA5WE6xe24NJ4pZv26m9x1H9FPfyiIwBhTOwY=; b=YLruMY8r1vjqEc9OKeC82gvXH4C9UyDZMonQnhIP72NhGaW1MgLJBnTRrW9L6uLRvd ebJTg1d214RL9UgRJHKzFBJBh9ugocEAkj1SjxbL25+KduqszB4IJ/yI4oxDJrhHb+Xs XwJ2SqGPKyqDIHygAS4QU38SQxCrgyHgBwGSG4eYFMUDSeMRxo5cR+x1T3zfZmtmqC2A xCRg9kGx8il5nMiqWqmAWMYY9EGJdpFvYJGCl1Ti07YZah0gfDAtp8dO2MdaQUllKvrb tY9aL4rko2x9jv+GavR/pairFVG8ksHdLw/XAL2Kj8I9rHd09XIBQ+W0uI6D+iPxjRE8 arBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689796320; x=1690401120; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JYOwNntA5WE6xe24NJ4pZv26m9x1H9FPfyiIwBhTOwY=; b=GYapbvqdTlafA1Itlngbm6YcL19dzcrhQ4KHdPrlY3UkGZegMNn0xaTPoW29EeEOMX bJ/Mt7WLCwma9Mz0GI0/Qos4zWBC1Qi1XN4mGLKR46/+GxkEs/M852cCQgbCDgq9chEq xoOAp8YGAcN1HYE03r3dgK6c9CYYzAhrRKCZ6YHxKYU90zHCH5H1EwgNd+MHbX13ktWR 4BTAHZ+cFinxMgIKXPXi8hYz8HOGhxSvKm6v6ret6HW6B5CsHj2IoROcLkVbAuzqFwmG BUBVO7JZr/WPvOl0wjsocdBpWFm2LdJ9H5P2JhzJkSOf+5ez0b8FK6JuqmxlQasacuoE 9sDg== X-Gm-Message-State: ABy/qLaCr6NM/lBycJ2mff1WRZP3MxEX+xqfHY6cvpxlS0nvNiFmH7wR hLV/W6uYLJl8bmWGOj5BDXijqyFHGOcstZvkXH7mSstJPvwGBDANFANxPw== X-Received: by 2002:a67:f648:0:b0:443:59e3:f4f6 with SMTP id u8-20020a67f648000000b0044359e3f4f6mr1439304vso.22.1689796319725; Wed, 19 Jul 2023 12:51:59 -0700 (PDT) MIME-Version: 1.0 References: <20221219204619.2205248-1-allenwebb@google.com> <20230406190030.968972-1-allenwebb@google.com> <20230406190030.968972-9-allenwebb@google.com> In-Reply-To: From: Allen Webb Date: Wed, 19 Jul 2023 14:51:48 -0500 Message-ID: Subject: Re: [PATCH v10 08/11] build: Add modules.builtin.alias To: Luis Chamberlain Cc: "linux-modules@vger.kernel.org" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , gregkh@linuxfoundation.org, christophe.leroy@csgroup.eu, nick.alcock@oracle.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_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: X-Mailing-List: linux-kernel@vger.kernel.org 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=E2=80=AFAM Luis Chamberlain 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 > > --- > > .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)/mod= ules.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 .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 +=3D -T $(MODORDER) > > modpost-deps +=3D $(MODORDER) > > endif > > > > +ifneq ($(wildcard vmlinux.o),) > > +output-builtin.alias :=3D modules.builtin.alias > > +modpost-args +=3D -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=3D"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] undefin= ed! 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] undefine= d! 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] undef= ined! 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=3D"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 > >