From: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
To: Segher Boessenkool <segher@kernel.crashing.org>,
"Paul E. McKenney" <paulmck@kernel.org>
Cc: Shrikanth Hegde <sshegde@linux.ibm.com>,
Jirka Hladky <jhladky@redhat.com>,
maddy@linux.ibm.com, linuxppc-dev@lists.ozlabs.org,
mpe@ellerman.id.au, npiggin@gmail.com, bigeasy@linutronix.de,
will@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/1] powerpc: enable dynamic preemption
Date: Fri, 31 Jul 2026 06:59:07 +0200 [thread overview]
Message-ID: <7269d45e-93ea-450a-912b-d1ba6ba6eb8b@kernel.org> (raw)
In-Reply-To: <amuauJfgjA-dJEQM@gate>
Le 30/07/2026 à 20:40, Segher Boessenkool a écrit :
> On Thu, Jul 30, 2026 at 10:26:58AM -0700, Paul E. McKenney wrote:
>> On Thu, Jul 30, 2026 at 10:40:38PM +0530, Shrikanth Hegde wrote:
>>> Barrier are in core implementation, not in arch specific.
>
> "Compiler barrier"s are not actually a thing, it is not a barrier for
> anything. It's just telling the compiler that at the point of the
> "barrier" all the registers should hold the values that they
> conceptually do also *actually*.
>
> (In theory the compiler can sometimes prove it can do things that do not
> even guarantee that, but in practice this holds).
>
>> But barrier() is just "__asm__ __volatile__("": : :"memory")", which
>> does not emit any instructions. Or is this doing more machine-register
>> flushing/restoring than one might expect?
>
> (__volatile__ is redundant, any asm without outputs is always counted as
> volatile. If this wasn't true, GCC could always delete any such asm,
> since it has no side effects at all!
There is a comment for the volatile:
/* Optimization barrier */
#ifndef barrier
/* The "volatile" is due to gcc bugs */
# define barrier() __asm__ __volatile__("": : :"memory")
#endif
>
> People often think "volatile" asm is some magic that prohibits the
> compiler from optimising stuff, but it is not, it has very contrained
> and very specific meaning).
>
> Nope. The "memory" clobber says that all memory can be read and written
> in that asm, so any value that conceptually resides in memory there
> should have a stable value there. This can trigger some save/restore
> stuff, sure, but on all Power ABIs we have actual registers for pretty
> much everything, so nothing at all is done here.
>
>
> Segher
next prev parent reply other threads:[~2026-07-31 4:59 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-10 18:43 [PATCH v4 0/1] powerpc: Enable dynamic preemption Shrikanth Hegde
2025-02-10 18:43 ` [PATCH v4 1/1] powerpc: enable " Shrikanth Hegde
2026-07-26 18:33 ` Jirka Hladky
2026-07-27 4:18 ` Shrikanth Hegde
2026-07-27 10:13 ` Jirka Hladky
2026-07-27 10:28 ` Shrikanth Hegde
2026-07-27 10:35 ` Christophe Leroy (CS GROUP)
2026-07-27 16:12 ` Paul E. McKenney
2026-07-27 10:59 ` Jirka Hladky
2026-07-27 11:03 ` Shrikanth Hegde
2026-07-27 12:34 ` Shrikanth Hegde
2026-07-27 16:07 ` Paul E. McKenney
2026-07-27 16:50 ` Jirka Hladky
2026-07-27 17:10 ` Shrikanth Hegde
2026-07-27 18:29 ` Christophe Leroy (CS GROUP)
2026-07-28 5:27 ` Shrikanth Hegde
2026-07-28 16:21 ` Paul E. McKenney
2026-07-28 16:30 ` Paul E. McKenney
2026-07-30 13:01 ` Shrikanth Hegde
2026-07-30 14:51 ` Paul E. McKenney
2026-07-28 0:26 ` Jirka Hladky
2026-07-28 5:11 ` Shrikanth Hegde
2026-07-28 14:19 ` Jirka Hladky
2026-07-30 6:44 ` Shrikanth Hegde
2026-07-30 12:08 ` Jirka Hladky
2026-07-30 14:47 ` Paul E. McKenney
2026-07-30 15:08 ` Jirka Hladky
2026-07-30 16:26 ` Paul E. McKenney
2026-07-30 17:10 ` Shrikanth Hegde
2026-07-30 17:26 ` Paul E. McKenney
2026-07-30 18:40 ` Segher Boessenkool
2026-07-31 4:59 ` Christophe Leroy (CS GROUP) [this message]
2026-07-31 5:03 ` Christophe Leroy (CS GROUP)
2026-07-31 7:18 ` Jirka Hladky
2026-07-31 8:02 ` Shrikanth Hegde
2026-07-31 13:50 ` Jirka Hladky
2026-07-31 17:57 ` Shrikanth Hegde
2026-07-31 18:11 ` Paul E. McKenney
2026-08-03 4:51 ` Shrikanth Hegde
2026-08-03 15:27 ` Paul E. McKenney
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=7269d45e-93ea-450a-912b-d1ba6ba6eb8b@kernel.org \
--to=chleroy@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=jhladky@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=paulmck@kernel.org \
--cc=segher@kernel.crashing.org \
--cc=sshegde@linux.ibm.com \
--cc=will@kernel.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: 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.