From: Torin Carey <torin@tcarey.uk>
To: "Rogério Valentim Feitoza da Silva" <rogerio.silva3920@gmail.com>
Cc: FMDF <fmdefrancesco@gmail.com>, kernelnewbies@kernelnewbies.org
Subject: Re: Exporting cpu instruction set to kernel .config file
Date: Fri, 04 Mar 2022 11:18:12 +0000 [thread overview]
Message-ID: <YiH1cbPDK94fQOOW@kappa> (raw)
In-Reply-To: <CALgyNi3Pj4sFNwgbbGhRWjvwby1W6S+qc+uou_wRBn2uHESE1A@mail.gmail.com>
On Thu, Mar 03, 2022 at 09:52:50PM -0300, Rogério Valentim Feitoza da Silva wrote:
> No kernel should be compiled with compiler optimization, because the compiler
> might remove CPU instructions and code that might look "unnecessary" but
> are actually required.
IIRC a lot of the kernel is compiled with -O2. You could increase it,
but it's not necessarily a good idea:
On Mon, May 11, 2020 at 05:04:56PM -0700, Linus Torvalds wrote:
> I'm not convinced this is sensible.
>
> -O3 historically does bad things with gcc. Including bad things for
> performance. It traditionally makes code larger and often SLOWER.
>
> And I don't mean slower to compile (although that's an issue). I mean
> actually generating slower code.
>
> Things like trying to unroll loops etc makes very little sense in the
> kernel, where we very seldom have high loop counts for pretty much
> anything.
>
> There's a reason -O3 isn't even offered as an option.
>
> Maybe things have changed, and maybe they've improved. But I'd like to
> see actual numbers for something like this.
>
> Not inlining as aggressively is not necessarily a bad thing. It can
> be, of course. But I've actually also done gcc bugreports about gcc
> inlining too much, and generating _worse_ code as a result (ie
> inlinging things that were behind an "if (unlikely())" test, and
> causing the likely path to grow a stack fram and stack spills as a
> result).
>
> So just "O3 inlines more" is not a valid argument.
--
https://lore.kernel.org/lkml/CAHk-=wi87j=wj0ijkYZ3WoPVkZ9Fq1U2bLnQ66nk425B5kW0Cw@mail.gmail.com/
On the other hand, decreasing it is also probably not a good idea.
Torin
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
next prev parent reply other threads:[~2022-03-04 11:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-02 16:57 Exporting cpu instruction set to kernel .config file Guddla Rupesh
2022-03-03 1:05 ` FMDF
2022-03-03 1:20 ` FMDF
2022-03-03 15:21 ` Guddla Rupesh
[not found] ` <CAPj211vBPjs-rAHtjkQetzoOChHhaaPATBFfXNTmmnG0sGovVQ@mail.gmail.com>
2022-03-03 18:44 ` FMDF
2022-03-03 18:46 ` Fwd: " FMDF
2022-03-03 23:06 ` Valdis Klētnieks
[not found] ` <CALgyNi2MGdmjGzVnBQ+cnCg94-k3ZTeHpCik2D7HwBVtFbLLjA@mail.gmail.com>
2022-03-03 19:39 ` FMDF
2022-03-04 0:52 ` Rogério Valentim Feitoza da Silva
2022-03-04 11:18 ` Torin Carey [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-03-02 17:11 Torin Carey
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=YiH1cbPDK94fQOOW@kappa \
--to=torin@tcarey.uk \
--cc=fmdefrancesco@gmail.com \
--cc=kernelnewbies@kernelnewbies.org \
--cc=rogerio.silva3920@gmail.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