All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Turner <mattst88@gmail.com>,
	Waiman Long <waiman.long@hp.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Daniel J Blueman <daniel@numascale.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH v8 4/4] qrwlock: Use smp_store_release() in write_unlock()
Date: Thu, 16 Jan 2014 11:36:59 +0100	[thread overview]
Message-ID: <20140116103659.GO7572@laptop.programming.kicks-ass.net> (raw)
In-Reply-To: <CA+55aFydYLQeBq=4AQQp_4dAnq09ocLmde1LFaXiNAJ=wJzfFA@mail.gmail.com>

On Thu, Jan 16, 2014 at 06:39:23AM +0700, Linus Torvalds wrote:
> On Jan 16, 2014 6:22 AM, "Peter Zijlstra" <peterz@infradead.org> wrote:
> >
> > So while the primitive is called smp_store_release() the !SMP variant
> > still does:
> >
> >   *(volatile __type *) = ptr;
> >
> > which should not compile on any Alpha pre EV56, SMP or no for __type ==
> > u8.
> 
> I'm not sure where you get that "should not compile" theory from.
> 
> I'm pretty sure it will compile just fine. It will just generate the same
> standard read-modify-write sequence (and not using the ldl/stc sequence
> either). Do you have any actual reason to believe it won't, apart from your
> theoretical wishes of how the world should work?

No, I earlier even said it probably would compile. My usage of 'should'
comes from how we've 'defined' volatile/ACCESS_ONCE in
Documentation/memory-barriers.txt. According to those constraints the
rmw cycle is not proper code.

  parent reply	other threads:[~2014-01-16 10:37 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-13  2:47 [PATCH v8 4/4] qrwlock: Use smp_store_release() in write_unlock() Daniel J Blueman
2014-01-13  3:49 ` Paul E. McKenney
2014-01-13 16:41 ` Waiman Long
2014-01-14  2:28   ` Daniel J Blueman
2014-01-14 11:03     ` Peter Zijlstra
2014-01-14 15:25       ` Waiman Long
2014-01-14 17:08       ` Matt Turner
2014-01-14 18:01         ` Richard Henderson
2014-01-14 19:09           ` Waiman Long
2014-01-14 20:20             ` Peter Zijlstra
2014-01-14 23:44           ` Paul E. McKenney
2014-01-15  0:25             ` Linus Torvalds
2014-01-15  2:39               ` Paul E. McKenney
2014-01-15  8:07                 ` Peter Zijlstra
2014-01-15 20:53                   ` Paul E. McKenney
2014-01-15 23:21                     ` Peter Zijlstra
     [not found]                       ` <CA+55aFydYLQeBq=4AQQp_4dAnq09ocLmde1LFaXiNAJ=wJzfFA@mail.gmail.com>
2014-01-16 10:36                         ` Peter Zijlstra [this message]
2014-01-18 10:01                           ` Paul E. McKenney
2014-01-18 11:34                             ` Peter Zijlstra
2014-01-18 12:25                               ` Paul E. McKenney
2014-01-18 12:41                                 ` Peter Zijlstra
2014-01-18 21:22                                   ` Paul E. McKenney
2014-01-19  0:57                                     ` Linus Torvalds
2014-01-19  8:04                                       ` Paul E. McKenney
2014-01-19 19:56                                         ` Linus Torvalds
2014-01-20  0:52                                           ` Paul E. McKenney
2014-01-21 15:02                                         ` Waiman Long
2014-01-21 15:41                                           ` Peter Zijlstra
2014-01-21 16:16                                             ` Waiman Long
2014-01-15  3:08             ` Daniel J Blueman
  -- strict thread matches above, loose matches on Subject: below --
2014-01-08 16:59 [PATCH v8 0/4] qrwlock: Introducing a queue read/write lock implementation Waiman Long
2014-01-08 16:59 ` [PATCH v8 4/4] qrwlock: Use smp_store_release() in write_unlock() Waiman Long

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=20140116103659.GO7572@laptop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=daniel@numascale.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mattst88@gmail.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rth@twiddle.net \
    --cc=torvalds@linux-foundation.org \
    --cc=waiman.long@hp.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 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.