From: "Yin, Fengwei" <fengwei.yin@intel.com>
To: peterz@infradead.org, linux-kernel@vger.kernel.org
Cc: "He, Min" <min.he@intel.com>, "Zhao, Yakui" <yakui.zhao@intel.com>
Subject: About compiler memory barrier for atomic_set/atomic_read on x86
Date: Tue, 3 Sep 2019 21:23:41 +0800 [thread overview]
Message-ID: <256e8ee2-a23c-28e9-3988-8b77307c001a@intel.com> (raw)
Hi Peter,
There is one question regarding following commit:
commit 69d927bba39517d0980462efc051875b7f4db185
Author: Peter Zijlstra <peterz@infradead.org>
Date: Wed Apr 24 13:38:23 2019 +0200
x86/atomic: Fix smp_mb__{before,after}_atomic()
Recent probing at the Linux Kernel Memory Model uncovered a
'surprise'. Strongly ordered architectures where the atomic RmW
primitive implies full memory ordering and
smp_mb__{before,after}_atomic() are a simple barrier() (such as x86)
This change made atomic RmW operations include compiler barrier. And
made __smp_mb__before_atomic/__smp_mb__after_atomic not include compiler
barrier any more for x86.
We face the issue to handle atomic_set/atomic_read which is mapped to
WRITE_ONCE/READ_ONCE on x86. These two functions don't include compiler
barrier actually (if operator size is less than 8 bytes).
Before the commit 69d927bba39517d0980462efc051875b7f4db185, we could use
__smp_mb__before_atomic/__smp_mb__after_atomic together with these two
functions to make sure the memory order. It can't work after the commit
69d927bba39517d0980462efc051875b7f4db185. I am wandering whether
we should make atomic_set/atomic_read also include compiler memory
barrier on x86? Thanks.
Regards
Yin, Fengwei
next reply other threads:[~2019-09-03 13:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-03 13:23 Yin, Fengwei [this message]
2019-09-03 14:06 ` About compiler memory barrier for atomic_set/atomic_read on x86 Peter Zijlstra
2019-09-03 23:38 ` Yin, Fengwei
2019-09-04 5:34 ` Yin, Fengwei
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=256e8ee2-a23c-28e9-3988-8b77307c001a@intel.com \
--to=fengwei.yin@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=min.he@intel.com \
--cc=peterz@infradead.org \
--cc=yakui.zhao@intel.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 NNTP newsgroup(s).