All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Jessica Yu <jeyu@kernel.org>, linux-kernel@vger.kernel.org
Cc: Matthias Maennich <maennich@google.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] export.h: reduce __ksymtab_strings string duplication by using "MS" section flags
Date: Thu, 21 Nov 2019 11:51:31 +0100	[thread overview]
Message-ID: <93d3936d-0bc4-9639-7544-42a324f01ac1@rasmusvillemoes.dk> (raw)
In-Reply-To: <20191120145110.8397-1-jeyu@kernel.org>

On 20/11/2019 15.51, Jessica Yu wrote:
> 
> We can alleviate this situation by utilizing the SHF_MERGE and
> SHF_STRING section flags. SHF_MERGE|SHF_STRING indicate to the linker
> that the data in the section are null-terminated strings 

[pet peeve: nul, not null.]

> As of v5.4-rc5, the following statistics were gathered with x86
> defconfig with approximately 10.7k exported symbols.
> 
> Size of __ksymtab_strings in vmlinux:
> -------------------------------------
> v5.4-rc5: 213834 bytes
> v5.4-rc5 with commit c3a6cf19e695: 224455 bytes
> v5.4-rc5 with this patch: 205759 bytes
> 
> So, we already see memory savings of ~8kB compared to vanilla -rc5 and
> savings of nearly 18.7kB compared to -rc5 with commit c3a6cf19e695 on top.

Yippee :) Thanks for picking up the ball and sending this.

>  /*
> - * note on .section use: @progbits vs %progbits nastiness doesn't matter,
> - * since we immediately emit into those sections anyway.
> + * note on .section use: we specify @progbits vs %progbits since usage of
> + * "M" (SHF_MERGE) section flag requires it.
>   */
> +
> +#ifdef CONFIG_ARM
> +#define ARCH_PROGBITS %progbits
> +#else
> +#define ARCH_PROGBITS @progbits
> +#endif

Did you figure out a way to determine if ARM is the only odd one? I was
just going by gas' documentation which mentions ARM as an example, but
doesn't really provide a way to know what each arch uses. I suppose 0day
will tell us shortly.

If we want to avoid arch-ifdefs in these headers (and that could become
unwieldy if ARM is not the only one) I think one could add a
asm-generic/progbits.h, add progbits.h to mandatory-y in
include/asm-generic/Kbuild, and then just provide a progbits.h on ARM
(and the other exceptions) - then I think the kbuild logic automatically
makes "#include <asm/progbits.h>" pick up the right one. And the header
could define ARCH_PROGBITS with or without the double quotes depending
on __ASSEMBLY__.

OTOH, adding a whole new header just for this may be overkill.

Rasmus

  parent reply	other threads:[~2019-11-21 10:51 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-20 14:51 [PATCH] export.h: reduce __ksymtab_strings string duplication by using "MS" section flags Jessica Yu
2019-11-20 15:02 ` Jessica Yu
2019-11-21 10:51 ` Rasmus Villemoes [this message]
2019-11-21 16:09   ` Jessica Yu
2019-11-21 16:53     ` Will Deacon
2019-11-22 11:44     ` Masahiro Yamada
2019-11-25  9:29       ` Rasmus Villemoes
2019-11-25  9:45         ` Jessica Yu
2019-11-25 15:42 ` [PATCH v2] " Jessica Yu
2019-11-26  8:32   ` Masahiro Yamada
2019-11-26  9:55     ` Jessica Yu
2019-11-26 13:56     ` Matthias Maennich
2019-11-26 15:31       ` Jessica Yu
2019-11-26 16:02         ` Matthias Maennich
2019-11-26 16:12         ` Masahiro Yamada
2019-11-26 16:48           ` Jessica Yu
2019-12-05 16:42             ` Matthias Maennich
2019-12-06 12:41   ` [PATCH v3] " Jessica Yu
2019-12-12  6:22     ` Masahiro Yamada
2019-12-12 10:36       ` Jessica Yu
2019-12-12 14:16     ` [PATCH v4] " Jessica Yu
2019-12-12 14:29       ` Matthias Maennich
2019-12-16  9:41         ` Jessica Yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=93d3936d-0bc4-9639-7544-42a324f01ac1@rasmusvillemoes.dk \
    --to=linux@rasmusvillemoes.dk \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=jeyu@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maennich@google.com \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.