Message ID | 20221216-objtool-memory-v2-5-17968f85a464@weissschuh.net |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp1461011wrt; Tue, 27 Dec 2022 08:05:44 -0800 (PST) X-Google-Smtp-Source: AMrXdXuYDXRcHKrlCjDlHDXerzoYRA6hNtXSeiYXRkjNujkdUvCnG9qGdxBgEbHSSVvgQdBP7YzS X-Received: by 2002:a17:906:688b:b0:7c1:5768:5fc9 with SMTP id n11-20020a170906688b00b007c157685fc9mr16264894ejr.43.1672157143956; Tue, 27 Dec 2022 08:05:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672157143; cv=none; d=google.com; s=arc-20160816; b=D2jhWGi2zNAgBhnjtlM73GFZtnilfkIGrRyCOd6lafVlOfD5fM79xOYTJ6TIu9lEXY xztoGmZROAlhPYZlOvWlu9j3RwXfMSKdMAh4ViZa/+Qsh0iJ5N6oNCnzmdrvO2NJKARJ RjpuMS6rRbH/d39nD5/E3W+1jwbDYrKoEPzsHgkGW2GKbaSUBvaq/uiyyP8UW2XvGYu0 z7v9OrZ0iePCgCNypv0/Hq9HB1Va47fBvoygqZhwHLXsUZrz/StvlERRoWn7vGmvgMVP jrkS9gGi5MWn3j9zRpzEBIJbJp1qoLKzjiJtnKNHW1SN+SECkMmnkiSLKZb0Yxy0ViVa 6k1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:dkim-signature :from; bh=UPKYUXhz5W0OEToyOJwznXcU5mqY9LQXhFytpkfal5k=; b=LvlcZ5LhZ09iYuQxPHNMtTxZRX+7+G4BGCQ4etZ7NJmMiG+C8qOIYQQXSoblHGBIjs 2o0w3Rx78AuPXjg5j3WTHmOHOfOhmz7oaAjCLWXVI+0aDAC86nnkzbEPHvB6T+Yj7hSz YHFXg9o2W53hjMU4JXlreSyzgFVl/uSBOsZ8Zm27u+SPCi7EYqnmERY1QZ6ExkwDEWtk krCkbK6HqBYS/HLLioZqVbfRXBrP3RCnLPf1NXfhQsRbbVKtIH6f6BRKRDyxQH8PgANA dfscge3Q4GSMi0G4SO8iC4WHf/gn6AN8osGxGKNe65IH2q+VvLdwtCaj5J+0bUfz47lQ 4YQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@weissschuh.net header.s=mail header.b="EMe/icwp"; 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o25-20020aa7c519000000b004865244368fsi2792604edq.334.2022.12.27.08.05.19; Tue, 27 Dec 2022 08:05:43 -0800 (PST) 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=fail header.i=@weissschuh.net header.s=mail header.b="EMe/icwp"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231417AbiL0QDc (ORCPT <rfc822;eddaouddi.ayoub@gmail.com> + 99 others); Tue, 27 Dec 2022 11:03:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47076 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231608AbiL0QCv (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 27 Dec 2022 11:02:51 -0500 Received: from todd.t-8ch.de (todd.t-8ch.de [IPv6:2a01:4f8:c010:41de::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B9AC860DF for <linux-kernel@vger.kernel.org>; Tue, 27 Dec 2022 08:02:49 -0800 (PST) From: Thomas =?utf-8?q?Wei=C3=9Fschuh?= <linux@weissschuh.net> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=weissschuh.net; s=mail; t=1672156966; bh=HMfXPM4QGrr46ln+5URVoZikc1BOiA+8cDROM3xuWNg=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=EMe/icwpCrtDDLc2F9MA+Ztlf16gn5RUk7Yzc0xtAs8c0WQ9/mir7JknzUycNOhVY Go3Wkg3o0QiBbV0AFrqApoOHeNmo4L9Q+6aZU2svuuG6biaynAGmx5CUmT1C2Vn3Mk GUcU08WMe9YL8M5Pzvdh5qpd5BcA8M6H0J7cNFzk= Date: Tue, 27 Dec 2022 16:01:01 +0000 Subject: [PATCH v2 5/8] objtool: reduce memory usage of struct reloc MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Message-Id: <20221216-objtool-memory-v2-5-17968f85a464@weissschuh.net> References: <20221216-objtool-memory-v2-0-17968f85a464@weissschuh.net> In-Reply-To: <20221216-objtool-memory-v2-0-17968f85a464@weissschuh.net> To: Josh Poimboeuf <jpoimboe@kernel.org>, Peter Zijlstra <peterz@infradead.org> Cc: linux-kernel@vger.kernel.org, Thomas =?utf-8?q?Wei=C3=9Fschuh?= <linux@weissschuh.net> X-Mailer: b4 0.11.0 X-Developer-Signature: v=1; a=ed25519-sha256; t=1672156865; l=1624; i=linux@weissschuh.net; s=20221212; h=from:subject:message-id; bh=HMfXPM4QGrr46ln+5URVoZikc1BOiA+8cDROM3xuWNg=; b=aQ7IAbiGlCMxnLDaQjHg0BDIPnl012xb3SFB40A9z7vKTalZQK3yit84aV22CrH7wWZWCUoqz2Df A6uktE2gA3vVzsVDRuuuZxI3CCC+KycU/RoK1bmhpvzlMS/nRTjE X-Developer-Key: i=linux@weissschuh.net; a=ed25519; pk=KcycQgFPX2wGR5azS7RhpBqedglOZVgRPfdFSPB1LNw= X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,SPF_HELO_NONE,SPF_PASS autolearn=no 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?1753383849077572638?= X-GMAIL-MSGID: =?utf-8?q?1753383849077572638?= |
Series |
reduce maximum memory usage
|
|
Commit Message
Thomas Weißschuh
Dec. 27, 2022, 4:01 p.m. UTC
Use a smaller type for the relocation type and move it to a location in
the structure where it avoids wasted padding bytes.
Technically ELF could use up to four bytes for the type.
But until now only types up to number 43 have been defined.
Reduce the size of struct reloc on x86_64 from 120 to 112 bytes.
This structure is allocated a lot and never freed.
This reduces maximum memory usage while processing vmlinux.o from
3035668 KB to 2919716 KB (-3.8%) on my notebooks "localmodconfig".
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
tools/objtool/elf.c | 3 +++
tools/objtool/include/objtool/elf.h | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
Comments
Hi, Thomas! Is this likely to cause most RELOC failures? As shown in the following example: #include <bfd.h> #include <stdio.h> int main(void) { printf("%d\n", BFD_RELOC_S12Z_OPR); return 0; } The BFD_RELOC_S12Z_OPR equal to 2366. Best wishes. Rong Tao
Hi Rong, On Thu, Dec 29, 2022 at 09:33:32AM +0800, Rong Tao wrote: > Is this likely to cause most RELOC failures? As shown in the following > example: > > #include <bfd.h> > #include <stdio.h> > > int main(void) > { > printf("%d\n", BFD_RELOC_S12Z_OPR); > return 0; > } > > The BFD_RELOC_S12Z_OPR equal to 2366. I'm not familiar with libbfd, so please correct me if I'm wrong. To me BFD_RELOC_S12Z_OPR looks like a value that is only used by libbfd. objtool does not use libbfd. The only values that objtools should see for the relocation types are the R_* constants from elf.h as they are used by the compiler and linker in the raw elf binary files. These never exceed the value 255, one byte. Indeed they seem to have been explicitly chosen like this. $ grep 'define R_.*NUM' /usr/include/elf.h #define R_68K_NUM 43 #define R_386_NUM 44 #define R_SPARC_NUM 253 #define R_MIPS_NUM 128 #define R_ALPHA_NUM 46 #define R_ARM_NUM 256 #define R_390_NUM 62 #define R_CRIS_NUM 20 #define R_X86_64_NUM 43 #define R_MN10300_NUM 35 #define R_M32R_NUM 256 /* Keep this the last entry. */ #define R_TILEPRO_NUM 130 #define R_TILEGX_NUM 130 #define R_RISCV_NUM 59 These _NUM constants are the highest actually used values, plus one. So all real values are smaller than 256. Thomas
Hi, Thomas:
In /usr/include/elf.h has:
#define ELF32_R_TYPE(val) ((val) & 0xff)
#define ELF64_R_TYPE(i) ((i) & 0xffffffff)
^^^^^^^^^^
So, I still feel that keeping 'unsigned int' is a good option. Can we just
use __attribute__((packed)) for wasted padding bytes?
Reviewed-by: Rong Tao <rongtao@cestc.cn>
Hi Rong, On Thu, Dec 29, 2022 at 11:29:07AM +0800, Rong Tao wrote: > Hi, Thomas: > > In /usr/include/elf.h has: > > #define ELF32_R_TYPE(val) ((val) & 0xff) > #define ELF64_R_TYPE(i) ((i) & 0xffffffff) > ^^^^^^^^^^ > > So, I still feel that keeping 'unsigned int' is a good option. Can we just > use __attribute__((packed)) for wasted padding bytes? As the struct contains addresses, packing it will create a ton of compiler warnings and will be much more likely to break than reducing the width of 'type'. Given that reducing the width of 'type' * is currently absolutely safe, * is unlikely to break in the future, as the elf designers seem to be actively trying to stay within this range anyways, * saves 8 bytes from a very heavily allocated struct, having a measurable impact on the build process, I continue to propose this aproach. Let's let the maintainers decide. Thomas
On Tue, Dec 27, 2022 at 04:01:01PM +0000, Thomas Weißschuh wrote: > void elf_reloc_set_type(struct reloc *reloc, int type) > { > + if (type >= (1U << (8 * sizeof(reloc->type)))) > + WARN("reloc->type out of range: %d", type); > + > reloc->type = type; > } > diff --git a/tools/objtool/include/objtool/elf.h b/tools/objtool/include/objtool/elf.h > index 33ec6cf72325..2b5becad5a0a 100644 > --- a/tools/objtool/include/objtool/elf.h > +++ b/tools/objtool/include/objtool/elf.h > @@ -77,10 +77,10 @@ struct reloc { > struct symbol *sym; > struct list_head sym_reloc_entry; > unsigned long offset; > - unsigned int type; > s64 addend; > int idx; > bool jump_table_start; > + unsigned char type; > }; I'd rather not because a) the helper function isn't very intuitive and we'll probably forget to use it b) some arches need more than 256 types (see for example aarch64 which objtool may need to support one of these days) That said, feel free to rearrange the struct fields to at least get some of those bytes back.
diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c index ee355beb0d82..182452adaa71 100644 --- a/tools/objtool/elf.c +++ b/tools/objtool/elf.c @@ -1474,5 +1474,8 @@ void elf_close(struct elf *elf) void elf_reloc_set_type(struct reloc *reloc, int type) { + if (type >= (1U << (8 * sizeof(reloc->type)))) + WARN("reloc->type out of range: %d", type); + reloc->type = type; } diff --git a/tools/objtool/include/objtool/elf.h b/tools/objtool/include/objtool/elf.h index 33ec6cf72325..2b5becad5a0a 100644 --- a/tools/objtool/include/objtool/elf.h +++ b/tools/objtool/include/objtool/elf.h @@ -77,10 +77,10 @@ struct reloc { struct symbol *sym; struct list_head sym_reloc_entry; unsigned long offset; - unsigned int type; s64 addend; int idx; bool jump_table_start; + unsigned char type; }; void elf_reloc_set_type(struct reloc *reloc, int type);