From: Vincent MAILHOL <mailhol.vincent@wanadoo.fr>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, Yury Norov <yury.norov@gmail.com>,
Nick Desaulniers <ndesaulniers@google.com>,
Douglas Anderson <dianders@chromium.org>,
Kees Cook <keescook@chromium.org>,
Petr Mladek <pmladek@suse.com>,
Randy Dunlap <rdunlap@infradead.org>,
Zhaoyang Huang <zhaoyang.huang@unisoc.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Marco Elver <elver@google.com>, Brian Cain <bcain@quicinc.com>,
Matthew Wilcox <willy@infradead.org>,
"Paul E . McKenney" <paulmck@kernel.org>,
linux-hexagon@vger.kernel.org, linux-m68k@lists.linux-m68k.org
Subject: Re: [PATCH v3 1/5] m68k/bitops: force inlining of all bitops functions
Date: Sun, 7 Jan 2024 21:01:34 +0900 [thread overview]
Message-ID: <CAMZ6RqJyJsucRHnuwj87gC9H9hZm9UwC8vAxEJHEPvM-sY=5DA@mail.gmail.com> (raw)
In-Reply-To: <CAMuHMdUvqY4VLDS0mW2VbSzTmef9xt+F3FCpRj5-Mv+KeOqyXg@mail.gmail.com>
On Tue. 2 janv. 2024 at 19:28, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Vincent,
>
> Thanks for your patch!
Thanks for the review and for running the benchmark.
> On Sun, Dec 17, 2023 at 8:13 AM Vincent Mailhol
> <mailhol.vincent@wanadoo.fr> wrote:
> > The inline keyword actually does not guarantee that the compiler will
> > inline a functions. Whenever the goal is to actually inline a
> > function, __always_inline should always be preferred instead.
> >
> > On an allyesconfig, with GCC 13.2.1, it saves roughly 5 KB.
> >
> > $ size --format=GNU vmlinux.before vmlinux.after
> > text data bss total filename
> > 60449738 70975612 2288988 133714338 vmlinux.before
> > 60446534 70972412 2289596 133708542 vmlinux.after
>
> With gcc 9.5.0-1ubuntu1~22.04, the figures are completely different
> (i.e. a size increase):
Those results are not normal, there should not be such a big
discrepancy between two versions of the same compiler. I double
checked everything and found out that I made a mistake when computing
the figures: not sure what exactly, but at some point, the ASLR seeds
(or other similar randomization feature) got reset and so, the
decrease I witnessed was just a "lucky roll".
After rerunning the benchmark (making sure to keep every seeds), I got
similar results as you:
text data bss total filename
60449738 70975356 2288988 133714082
vmlinux_allyesconfig.before_this_series
60446534 70979068 2289596 133715198
vmlinux_allyesconfig.after_first_patch
60429746 70979132 2291676 133700554
vmlinux_allyesconfig.final_second_patch
Note that there are still some kind of randomness on the data segment
as shown in those other benchmarks I run:
text data bss total filename
60449738 70976124 2288988 133714850
vmlinux_allyesconfig.before_this_series
60446534 70980092 2289596 133716222
vmlinux_allyesconfig.after_first_patch
60429746 70979388 2291676 133700810
vmlinux_allyesconfig.after_second_patch
text data bss total filename
60449738 70975612 2288988 133714338
vmlinux_allyesconfig.before_this_series
60446534 70980348 2289596 133716478
vmlinux_allyesconfig.after_first_patch
60429746 70979900 2291676 133701322
vmlinux_allyesconfig.after_second_patch
But the error margin is within 1K.
So, in short, I inlined some functions which I shouldn't have. I am
preparing a v4 in which I will only inline the bit-find functions
(namely: __ffs(), ffs(), ffz(), __fls(), fls() and fls64()). Here are
the new figures:
text data bss total filename
60453552 70955485 2288620 133697657
vmlinux_allyesconfig.before_this_series
60450304 70953085 2289260 133692649
vmlinux_allyesconfig.after_first_patch
60433536 70952637 2291340 133677513
vmlinux_allyesconfig.after_second_patch
N.B. The new figures were after a rebase, so do not try to compare
with the previous benchmarks. I will send the v4 soon, after I finish
to update the patch comments and double check things.
Concerning the other functions in bitops.h, there may be some other
ones worth a __always_inline. But I will narrow the scope of this
series only to the bit-find function. If a good samaritan wants to
investigate the other functions, go ahead!
Yours sincerely,
Vincent Mailhol
> allyesconfig:
>
> text data bss total filename
> 58878600 72415994 2283652 133578246 vmlinux.before
> 58882250 72419706 2284004 133585960 vmlinux.after
>
> atari_defconfig:
>
> text data bss total filename
> 4112060 1579862 151680 5843602 vmlinux-v6.7-rc8
> 4117008 1579350 151680 5848038
> vmlinux-v6.7-rc8-1-m68k-bitops-force-inlining
>
> The next patch offsets that for allyesconfig, but not for atari_defconfig.
>
> > Reference: commit 8dd5032d9c54 ("x86/asm/bitops: Force inlining of
> > test_and_set_bit and friends")
>
> Please don't split lines containing tags.
>
> > Link: https://git.kernel.org/torvalds/c/8dd5032d9c54
> >
> > Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
>
> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
next prev parent reply other threads:[~2024-01-07 12:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20221111081316.30373-1-mailhol.vincent@wanadoo.fr>
2023-12-17 7:12 ` [PATCH v3 0/5] bitops: optimize code and add tests Vincent Mailhol
2023-12-17 7:12 ` [PATCH v3 1/5] m68k/bitops: force inlining of all bitops functions Vincent Mailhol
2024-01-02 10:28 ` Geert Uytterhoeven
2024-01-07 12:01 ` Vincent MAILHOL [this message]
2023-12-17 7:12 ` [PATCH v3 2/5] m68k/bitops: use __builtin_{clz,ctzl,ffs} to evaluate constant expressions Vincent Mailhol
2024-01-02 10:49 ` Geert Uytterhoeven
2023-12-17 7:12 ` [PATCH v3 3/5] hexagon/bitops: force inlining of all bitops functions Vincent Mailhol
2023-12-17 7:12 ` [PATCH v3 4/5] hexagon/bitops: use __builtin_{clz,ctzl,ffs} to evaluate constant expressions Vincent Mailhol
2023-12-17 7:12 ` [PATCH v3 5/5] lib: test_bitops: add compile-time optimization/evaluations assertions Vincent Mailhol
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='CAMZ6RqJyJsucRHnuwj87gC9H9hZm9UwC8vAxEJHEPvM-sY=5DA@mail.gmail.com' \
--to=mailhol.vincent@wanadoo.fr \
--cc=akpm@linux-foundation.org \
--cc=bcain@quicinc.com \
--cc=dianders@chromium.org \
--cc=elver@google.com \
--cc=geert+renesas@glider.be \
--cc=geert@linux-m68k.org \
--cc=keescook@chromium.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=ndesaulniers@google.com \
--cc=paulmck@kernel.org \
--cc=pmladek@suse.com \
--cc=rdunlap@infradead.org \
--cc=willy@infradead.org \
--cc=yury.norov@gmail.com \
--cc=zhaoyang.huang@unisoc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).