From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jonas Oberhauser <jonas.oberhauser@huaweicloud.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Boqun Feng <boqun.feng@gmail.com>,
linux-kernel@vger.kernel.org, rcu@vger.kernel.org,
linux-mm@kvack.org, lkmm@lists.linux.dev,
"Paul E. McKenney" <paulmck@kernel.org>,
Frederic Weisbecker <frederic@kernel.org>,
Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
Joel Fernandes <joel@joelfernandes.org>,
Josh Triplett <josh@joshtriplett.org>,
Uladzislau Rezki <urezki@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Zqiang <qiang.zhang1211@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
Waiman Long <longman@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Kent Overstreet <kent.overstreet@gmail.com>,
Vlastimil Babka <vbabka@suse.cz>,
maged.michael@gmail.com,
Neeraj Upadhyay <neeraj.upadhyay@amd.com>
Subject: Re: [RFC PATCH 1/4] hazptr: Add initial implementation of hazard pointers
Date: Thu, 26 Sep 2024 09:54:33 -0700 [thread overview]
Message-ID: <CAHk-=wifOW0VEh6uL3sHSaAUA46YmPDS9Wh5HnNC2JyOiXVA=Q@mail.gmail.com> (raw)
In-Reply-To: <54487a36-f74c-46c3-aed7-fc86eaaa9ca2@huaweicloud.com>
On Thu, 26 Sept 2024 at 09:40, Jonas Oberhauser
<jonas.oberhauser@huaweicloud.com> wrote:
>
> Boqun seems to be unhappy with a barrier though, because it would
> theoretically also forbid unrelated optimizations.
Well, doing a "barrier()" is kind of a big hammer thing, but honestly,
I don't think we've ever seen any real situation where it makes a
noticeable difference. Yes, it can pessimize compiler output more than
strictly necessary, but the kind of code generation issues it causes
tends to be the non-problematic kind (and particularly the kind that
even a trivial OoO core will deal with well).
We do have some more directed compiler barriers available, and this
code might be able to use OPTIMIZER_HIDE_VAR() for example. It's kind
of a "single variable value barrier".
Honestly, we don't use it much. It just tends to be _too_specific. But
it is there if somebody wants to use it.
> But I have not seen any evidence that there are any unrelated
> optimizations going on in the first place that would be forbidden by this.
Compared to something like "smp_mb()", which is not just a compiler
barrier but also generates typically very expensive instructions that
completely mess with an OoO core, a regular compiler barrier is a
complete non-issue. When you have those two close to each other, you'd
have to make up some very odd situation where the plain "barrier()" is
even noticeable.
Linus
next prev parent reply other threads:[~2024-09-26 16:54 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240917143402.930114-1-boqun.feng@gmail.com>
[not found] ` <20240917143402.930114-2-boqun.feng@gmail.com>
[not found] ` <CA757E86-2AE4-4077-A07A-679E3BFDBC34@gmail.com>
2024-09-19 6:56 ` [RFC PATCH 1/4] hazptr: Add initial implementation of hazard pointers Boqun Feng
2024-09-19 18:07 ` Jonas Oberhauser
[not found] ` <CAJhGHyD8MzUssfuKSGnu1arnayNOyBnUA03vYB0WWwbE3WzoZg@mail.gmail.com>
2024-09-19 7:10 ` Boqun Feng
2024-09-19 12:33 ` Alan Huang
2024-09-19 13:57 ` Alan Huang
2024-09-19 18:58 ` Boqun Feng
2024-09-19 19:53 ` Alan Huang
2024-09-19 16:10 ` Alan Huang
[not found] ` <CAG48ez0VN8oZcqhdzkWQgNv6bwUN=MUu5EacLg5iPvMQL+R-Qg@mail.gmail.com>
2024-09-19 20:30 ` Jonas Oberhauser
2024-09-20 7:43 ` Jonas Oberhauser
[not found] ` <55975a55-302f-4c45-bfcc-192a8a1242e9@huaweicloud.com>
[not found] ` <ZvPfmAp_2mDkI3ss@boqun-archlinux>
[not found] ` <f5aeeeda-c725-422a-9481-4795bd3ade0f@huaweicloud.com>
2024-09-25 10:45 ` Boqun Feng
2024-09-25 11:59 ` Mathieu Desnoyers
2024-09-25 12:16 ` Boqun Feng
2024-09-25 12:47 ` Mathieu Desnoyers
2024-09-25 13:10 ` Mathieu Desnoyers
2024-09-25 13:20 ` Mathieu Desnoyers
2024-09-26 6:16 ` Mathieu Desnoyers
2024-09-26 15:53 ` Jonas Oberhauser
2024-09-26 16:12 ` Linus Torvalds
2024-09-26 16:40 ` Jonas Oberhauser
2024-09-26 16:54 ` Linus Torvalds [this message]
2024-09-27 0:01 ` Boqun Feng
2024-09-27 1:30 ` Mathieu Desnoyers
2024-09-27 1:37 ` Boqun Feng
2024-09-27 4:28 ` Boqun Feng
2024-09-27 10:59 ` Mathieu Desnoyers
2024-09-27 14:43 ` Mathieu Desnoyers
2024-09-27 15:22 ` Mathieu Desnoyers
2024-09-27 16:06 ` Alan Huang
2024-09-27 16:44 ` Linus Torvalds
2024-09-27 17:15 ` Mathieu Desnoyers
2024-09-27 17:23 ` Linus Torvalds
2024-09-27 17:51 ` Mathieu Desnoyers
2024-09-27 18:13 ` Linus Torvalds
2024-09-27 19:12 ` Jonas Oberhauser
2024-09-27 19:28 ` Linus Torvalds
2024-09-27 20:24 ` Linus Torvalds
2024-09-27 20:02 ` Mathieu Desnoyers
2024-09-27 1:20 ` Mathieu Desnoyers
2024-09-27 4:38 ` Boqun Feng
2024-09-27 19:23 ` Jonas Oberhauser
2024-09-27 20:10 ` Mathieu Desnoyers
2024-09-27 22:18 ` Jonas Oberhauser
2024-09-28 22:10 ` Alan Huang
2024-09-28 23:12 ` Alan Huang
2024-09-25 12:19 ` Jonas Oberhauser
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='CAHk-=wifOW0VEh6uL3sHSaAUA46YmPDS9Wh5HnNC2JyOiXVA=Q@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=boqun.feng@gmail.com \
--cc=frederic@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=jonas.oberhauser@huaweicloud.com \
--cc=josh@joshtriplett.org \
--cc=kent.overstreet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkmm@lists.linux.dev \
--cc=longman@redhat.com \
--cc=maged.michael@gmail.com \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@redhat.com \
--cc=neeraj.upadhyay@amd.com \
--cc=neeraj.upadhyay@kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=qiang.zhang1211@gmail.com \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=urezki@gmail.com \
--cc=vbabka@suse.cz \
--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 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).