From: Segher Boessenkool <segher@kernel.crashing.org> To: Nicholas Piggin <npiggin@gmail.com> Cc: linux-kernel@vger.kernel.org, Paul Mackerras <paulus@samba.org>, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v2 1/2] powerpc/bug: Remove specific powerpc BUG_ON() and WARN_ON() on PPC32 Date: Thu, 26 Aug 2021 07:49:01 -0500 [thread overview] Message-ID: <20210826124901.GY1583@gate.crashing.org> (raw) In-Reply-To: <1629946707.f6ptz0tgle.astroid@bobo.none> Hi! On Thu, Aug 26, 2021 at 01:26:14PM +1000, Nicholas Piggin wrote: > Excerpts from Segher Boessenkool's message of August 19, 2021 1:06 am: > > On Fri, Aug 13, 2021 at 04:08:13PM +1000, Nicholas Piggin wrote: > >> This one possibly the branches end up in predictors, whereas conditional > >> trap is always just speculated not to hit. Branches may also have a > >> throughput limit on execution whereas trap could be more (1 per cycle > >> vs 4 per cycle on POWER9). > > > > I thought only *taken* branches are just one per cycle? > > Taken branches are fetched by the front end at one per cycle (assuming > they hit the BTAC), but all branches have to be executed by BR at one > per cycle This is not true. (Simple) predicted not-taken conditional branches are just folded out, never hit the issue queues. And they are fetched as many together as fit in a fetch group, can complete without limits as well. The BTAC is a frontend thing, used for target address prediction. It does not limit execution. Correctly predicted simple conditional branches just get their prediction validated (and that is not done in the execution units). Incorrectly predicted branches the same, but those cause a redirect and refetch. > > Internally *all* traps are conditional, in GCC. It also can optimise > > them quite well. There must be something in the kernel macros that > > prevents good optimisation. > > I did take a look at it at one point. > > One problem is that the kernel needs the address of the trap instruction > to create the entry for it. The other problem is that __builtin_trap > does not return so it can't be used for WARN. LLVM at least seems to > have a __builtin_debugtrap which does return. This is <https://gcc.gnu.org/PR99299>. > The first problem seems like the show stopper though. AFAIKS it would > need a special builtin support that does something to create the table > entry, or a guarantee that we could put an inline asm right after the > builtin as a recognized pattern and that would give us the instruction > following the trap. I'm not quite sure what this means. Can't you always just put a bla: asm(""); in there, and use the address of "bla"? If not, you need to say a lot more about what you actually want to do :-/ Segher
WARNING: multiple messages have this Message-ID (diff)
From: Segher Boessenkool <segher@kernel.crashing.org> To: Nicholas Piggin <npiggin@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>, Christophe Leroy <christophe.leroy@csgroup.eu>, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Michael Ellerman <mpe@ellerman.id.au>, Paul Mackerras <paulus@samba.org> Subject: Re: [PATCH v2 1/2] powerpc/bug: Remove specific powerpc BUG_ON() and WARN_ON() on PPC32 Date: Thu, 26 Aug 2021 07:49:01 -0500 [thread overview] Message-ID: <20210826124901.GY1583@gate.crashing.org> (raw) In-Reply-To: <1629946707.f6ptz0tgle.astroid@bobo.none> Hi! On Thu, Aug 26, 2021 at 01:26:14PM +1000, Nicholas Piggin wrote: > Excerpts from Segher Boessenkool's message of August 19, 2021 1:06 am: > > On Fri, Aug 13, 2021 at 04:08:13PM +1000, Nicholas Piggin wrote: > >> This one possibly the branches end up in predictors, whereas conditional > >> trap is always just speculated not to hit. Branches may also have a > >> throughput limit on execution whereas trap could be more (1 per cycle > >> vs 4 per cycle on POWER9). > > > > I thought only *taken* branches are just one per cycle? > > Taken branches are fetched by the front end at one per cycle (assuming > they hit the BTAC), but all branches have to be executed by BR at one > per cycle This is not true. (Simple) predicted not-taken conditional branches are just folded out, never hit the issue queues. And they are fetched as many together as fit in a fetch group, can complete without limits as well. The BTAC is a frontend thing, used for target address prediction. It does not limit execution. Correctly predicted simple conditional branches just get their prediction validated (and that is not done in the execution units). Incorrectly predicted branches the same, but those cause a redirect and refetch. > > Internally *all* traps are conditional, in GCC. It also can optimise > > them quite well. There must be something in the kernel macros that > > prevents good optimisation. > > I did take a look at it at one point. > > One problem is that the kernel needs the address of the trap instruction > to create the entry for it. The other problem is that __builtin_trap > does not return so it can't be used for WARN. LLVM at least seems to > have a __builtin_debugtrap which does return. This is <https://gcc.gnu.org/PR99299>. > The first problem seems like the show stopper though. AFAIKS it would > need a special builtin support that does something to create the table > entry, or a guarantee that we could put an inline asm right after the > builtin as a recognized pattern and that would give us the instruction > following the trap. I'm not quite sure what this means. Can't you always just put a bla: asm(""); in there, and use the address of "bla"? If not, you need to say a lot more about what you actually want to do :-/ Segher
next prev parent reply other threads:[~2021-08-26 12:52 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-13 16:38 [PATCH v2 1/2] powerpc/bug: Remove specific powerpc BUG_ON() and WARN_ON() on PPC32 Christophe Leroy 2021-04-13 16:38 ` Christophe Leroy 2021-04-13 16:38 ` [PATCH v2 2/2] powerpc/bug: Provide better flexibility to WARN_ON/__WARN_FLAGS() with asm goto Christophe Leroy 2021-04-13 16:38 ` Christophe Leroy 2021-08-13 6:19 ` Nicholas Piggin 2021-08-13 6:19 ` Nicholas Piggin 2021-08-15 3:49 ` Michael Ellerman 2021-08-15 3:49 ` Michael Ellerman 2021-08-25 21:25 ` Nathan Chancellor 2021-08-25 21:25 ` Nathan Chancellor 2021-08-26 3:21 ` Michael Ellerman 2021-08-26 3:21 ` Michael Ellerman 2021-08-26 6:37 ` Christophe Leroy 2021-08-26 6:37 ` Christophe Leroy 2021-08-26 13:47 ` Segher Boessenkool 2021-08-26 13:47 ` Segher Boessenkool 2021-08-26 14:45 ` Michael Ellerman 2021-08-26 14:45 ` Michael Ellerman 2021-08-26 14:53 ` Christophe Leroy 2021-08-26 14:53 ` Christophe Leroy 2021-08-26 14:12 ` Segher Boessenkool 2021-08-26 14:12 ` Segher Boessenkool 2021-08-26 18:54 ` Nathan Chancellor 2021-08-26 18:54 ` Nathan Chancellor 2021-08-26 23:55 ` Nathan Chancellor 2021-08-26 23:55 ` Nathan Chancellor 2021-08-27 7:53 ` Michael Ellerman 2021-08-27 7:53 ` Michael Ellerman 2021-08-13 6:08 ` [PATCH v2 1/2] powerpc/bug: Remove specific powerpc BUG_ON() and WARN_ON() on PPC32 Nicholas Piggin 2021-08-13 6:08 ` Nicholas Piggin 2021-08-18 15:06 ` Segher Boessenkool 2021-08-18 15:06 ` Segher Boessenkool 2021-08-26 3:26 ` Nicholas Piggin 2021-08-26 3:26 ` Nicholas Piggin 2021-08-26 12:49 ` Segher Boessenkool [this message] 2021-08-26 12:49 ` Segher Boessenkool 2021-08-26 13:57 ` Nicholas Piggin 2021-08-26 13:57 ` Nicholas Piggin 2021-08-26 14:37 ` Segher Boessenkool 2021-08-26 14:37 ` Segher Boessenkool 2021-08-26 15:04 ` Nicholas Piggin 2021-08-26 15:04 ` Nicholas Piggin 2021-08-26 15:30 ` Segher Boessenkool 2021-08-26 15:30 ` Segher Boessenkool 2021-08-27 1:28 ` Nicholas Piggin 2021-08-27 1:28 ` Nicholas Piggin 2021-08-18 13:38 ` Michael Ellerman 2021-08-18 13:38 ` Michael Ellerman
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=20210826124901.GY1583@gate.crashing.org \ --to=segher@kernel.crashing.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=npiggin@gmail.com \ --cc=paulus@samba.org \ /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: linkBe 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.