All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Yubin Ruan <ablacktshirt@gmail.com>
Cc: perfbook@vger.kernel.org
Subject: Re: [Question] different kinds of memory barrier
Date: Mon, 13 Feb 2017 11:06:00 -0800	[thread overview]
Message-ID: <20170213190600.GJ30506@linux.vnet.ibm.com> (raw)
In-Reply-To: <881f369d-4e5b-a335-6359-c5d7bf1bc086@gmail.com>

On Mon, Feb 13, 2017 at 09:55:50PM +0800, Yubin Ruan wrote:
> It have been mentioned in the book that there are three kinds of
> memory barriers: smp_rmb, smp_wmb, smp_mb
> 
> I am confused about their actual semantic:
> 
> The book says that(B.5 paragraph 2, perfbook2017.01.02a):
> 
> for smp_rmb():
>     "The effect of this is that a read memory barrier orders
>      only loads on the CPU that executes it, so that all loads
>      preceding the read memory barrier will appear to have
>      completed before any load following the read memory
>      barrier"
> 
> for smp_wmb():
>     "so that all stores preceding the write memory barrier will
>      appear to have completed before any store following the
>      write memory barrier"
> 
> I wonder, is there any primitive "X" which can guarantees:
>     "that all 'loads' preceding the X will appear to have completed
>      before any *store* following the X "
> 
> and similarly:
>     "that all 'store' preceding the X will appear to have completed
>      before any *load* following the X "
> 
> I know I can use the general smp_mb() for that, but that is a little
> too general.
> 
> Do I miss/mix anything ?

Well, the memory-ordering material is a bit dated.  There is some work
underway to come up with a better model, and I presented on it a couple
weeks ago:

http://www.rdrop.com/users/paulmck/scalability/paper/LinuxMM.2017.01.19a.LCA.pdf

This presentation calls out a tarball that includes some .html files
that have much better explanations, and this wording will hopefully
be reflected in an upcoming version of the book.  Here is a direct
URL for the tarball:

http://www.rdrop.com/users/paulmck/scalability/paper/LCA-LinuxMemoryModel.2017.01.15a.tgz 

							Thanx, Paul


  reply	other threads:[~2017-02-13 19:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-13 13:55 [Question] different kinds of memory barrier Yubin Ruan
2017-02-13 19:06 ` Paul E. McKenney [this message]
2017-02-14 10:35   ` Yubin Ruan
     [not found]     ` <20170216185845.GJ30506@linux.vnet.ibm.com>
     [not found]       ` <70c1256d-1045-f4df-3423-b326b28ff86d@gmail.com>
2017-02-17  9:20         ` Yubin Ruan
2017-02-17 15:35           ` Paul E. McKenney
2017-02-17 16:22             ` Yubin Ruan
2017-02-17 17:32               ` Paul E. McKenney
2017-02-18  5:07                 ` Yubin Ruan
2017-02-18  6:58                   ` Akira Yokosawa
2017-02-18 12:09                     ` Yubin Ruan

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=20170213190600.GJ30506@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=ablacktshirt@gmail.com \
    --cc=perfbook@vger.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.