Re: [RFC 10/12] x86, rwsem: simplify __down_write

2016-06-10 Thread Paul E. McKenney
On Thu, Jun 09, 2016 at 07:36:40PM +0200, Peter Zijlstra wrote: > On Thu, Jun 09, 2016 at 03:40:58PM +0100, David Howells wrote: > > Peter Zijlstra wrote: > > > > > Blergh; so looking at more asm there's still a few tricks we cannot do. > > > So while overall size is down, some paths do end up mo

Question about DEC Alpha memory ordering

2017-02-13 Thread Paul E. McKenney
Hello! We have a question about DEC Alpha memory ordering. Given the litmus test shown at the end of this email, some of us believe that DEC Alpha won't ever have both P0()'s and P1()'s READ_ONCE() calls return 1, but others believe otherwise. Our current Linux-kernel memory model assumes that i

Re: Question about DEC Alpha memory ordering

2017-02-13 Thread Paul E. McKenney
On Mon, Feb 13, 2017 at 01:53:27PM -0500, bob smith wrote: > On 2/13/17 1:39 PM, Paul E. McKenney wrote: > > can real DEC Alpha hardware end up with both instances of "r1" > > having the value 1? > > I thought this question reminded me of something, so I found this:

Re: Question about DEC Alpha memory ordering

2017-02-13 Thread Paul E. McKenney
On Mon, Feb 13, 2017 at 08:14:23PM +0100, Tobias Klausmann wrote: > Hi! > > On Mon, 13 Feb 2017, Paul E. McKenney wrote: > > On Mon, Feb 13, 2017 at 01:53:27PM -0500, bob smith wrote: > > > On 2/13/17 1:39 PM, Paul E. McKenney wrote: > > > > can real DEC Alpha

Re: Question about DEC Alpha memory ordering

2017-02-13 Thread Paul E. McKenney
On Tue, Feb 14, 2017 at 08:23:34AM +1300, Michael Cree wrote: > Hi Paul, > > On Mon, Feb 13, 2017 at 11:09:31AM -0800, Paul E. McKenney wrote: > > On Mon, Feb 13, 2017 at 01:53:27PM -0500, bob smith wrote: > > > On 2/13/17 1:39 PM, Paul E. McKenney wrote: > > >

Re: Question about DEC Alpha memory ordering

2017-02-13 Thread Paul E. McKenney
On Mon, Feb 13, 2017 at 04:06:21PM -0500, Alan Stern wrote: > On Mon, 13 Feb 2017, Paul E. McKenney wrote: > > > On Mon, Feb 13, 2017 at 08:14:23PM +0100, Tobias Klausmann wrote: > > > Hi! > > > > > > On Mon, 13 Feb 2017, Paul E. McKenney wrote: > >

[PATCH RFC 09/26] alpha: Remove spin_unlock_wait() arch-specific definitions

2017-06-29 Thread Paul E. McKenney
There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney Cc: Richard Henderso

Re: [RFC PATCH 1/2] arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tables

2017-09-28 Thread Paul E. McKenney
On Thu, Sep 28, 2017 at 09:45:35AM +0100, Will Deacon wrote: > On Thu, Sep 28, 2017 at 10:38:01AM +0200, Peter Zijlstra wrote: > > On Wed, Sep 27, 2017 at 04:49:28PM +0100, Will Deacon wrote: > > > In many cases, page tables can be accessed concurrently by either another > > > CPU (due to things li

Re: [RFC PATCH 1/2] arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tables

2017-09-28 Thread Paul E. McKenney
On Thu, Sep 28, 2017 at 04:49:54PM +0100, Will Deacon wrote: > On Thu, Sep 28, 2017 at 08:43:54AM -0700, Paul E. McKenney wrote: > > On Thu, Sep 28, 2017 at 09:45:35AM +0100, Will Deacon wrote: > > > On Thu, Sep 28, 2017 at 10:38:01AM +0200, Peter Zijlstra wrote: > > > &

Re: [RFC PATCH 1/2] arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tables

2017-09-28 Thread Paul E. McKenney
On Fri, Sep 29, 2017 at 07:59:09AM +1300, Michael Cree wrote: > On Thu, Sep 28, 2017 at 08:43:54AM -0700, Paul E. McKenney wrote: > > On Thu, Sep 28, 2017 at 09:45:35AM +0100, Will Deacon wrote: > > > On Thu, Sep 28, 2017 at 10:38:01AM +0200, Peter Zijlstra wrote: > > >

Re: [RFC PATCH 1/2] arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tables

2017-09-29 Thread Paul E. McKenney
On Fri, Sep 29, 2017 at 10:08:43AM +0100, Will Deacon wrote: > On Thu, Sep 28, 2017 at 05:58:30PM -0700, Paul E. McKenney wrote: > > On Fri, Sep 29, 2017 at 07:59:09AM +1300, Michael Cree wrote: > > > On Thu, Sep 28, 2017 at 08:43:54AM -0700, Paul E. McKenney wrote: > > >

Re: [RFC PATCH 1/2] arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tables

2017-10-03 Thread Paul E. McKenney
On Fri, Sep 29, 2017 at 05:33:49PM +0100, Will Deacon wrote: > On Fri, Sep 29, 2017 at 09:29:39AM -0700, Paul E. McKenney wrote: > > On Fri, Sep 29, 2017 at 10:08:43AM +0100, Will Deacon wrote: > > > On Thu, Sep 28, 2017 at 05:58:30PM -0700, Paul E. McKenney wrote: > > >

Re: [RFC PATCH 1/2] arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tables

2017-10-05 Thread Paul E. McKenney
On Thu, Oct 05, 2017 at 05:31:54PM +0100, Will Deacon wrote: > Hi Paul, > > On Tue, Oct 03, 2017 at 12:11:10PM -0700, Paul E. McKenney wrote: > > On Fri, Sep 29, 2017 at 05:33:49PM +0100, Will Deacon wrote: > > > On Fri, Sep 29, 2017 at 09:29:39AM -0700, Paul E. McKenn

Re: [RFC PATCH 1/2] arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tables

2017-10-05 Thread Paul E. McKenney
Oct 03, 2017 at 12:11:10PM -0700, Paul E. McKenney wrote: > > > On Fri, Sep 29, 2017 at 05:33:49PM +0100, Will Deacon wrote: > > > > On Fri, Sep 29, 2017 at 09:29:39AM -0700, Paul E. McKenney wrote: > > > > > On Fri, Sep 29, 2017 at 10:08:43AM +0100, Will Deacon

Do any Alpha systems include InfiniBand?

2017-10-20 Thread Paul E. McKenney
Hello, Michael, Do any of the DEC Alpha systems that run recent kernels have InfiniBand? Given my understanding of the history, I believe the answer to be "no". If I am wrong, please let me know, as I will otherwise interpret silence as assent. ;-)

Re: Do any Alpha systems include InfiniBand?

2017-10-20 Thread Paul E. McKenney
On Fri, Oct 20, 2017 at 01:00:14PM -0700, Matt Turner wrote: > On Fri, Oct 20, 2017 at 12:48 PM, Paul E. McKenney > wrote: > > Hello, Michael, > > > > Do any of the DEC Alpha systems that run recent kernels have InfiniBand? > > Given my understanding of the history,

Re: Do any Alpha systems include InfiniBand?

2017-10-23 Thread Paul E. McKenney
On Mon, Oct 23, 2017 at 09:59:21PM +1300, Michael Cree wrote: > On Fri, Oct 20, 2017 at 12:48:32PM -0700, Paul E. McKenney wrote: > > Do any of the DEC Alpha systems that run recent kernels have InfiniBand? > > Given my understanding of the history, I believe the answer to be &quo

Re: Do any Alpha systems include InfiniBand?

2017-10-23 Thread Paul E. McKenney
On Mon, Oct 23, 2017 at 06:16:25PM +0100, Will Deacon wrote: > On Mon, Oct 23, 2017 at 10:13:12AM -0700, Paul E. McKenney wrote: > > On Mon, Oct 23, 2017 at 09:59:21PM +1300, Michael Cree wrote: > > > On Fri, Oct 20, 2017 at 12:48:32PM -0700, Paul E. McKenney wrote: > > >

[PATCH tip/core/rcu 16/21] drivers/infiniband: Remove now-redundant smp_read_barrier_depends()

2017-12-01 Thread Paul E. McKenney
is bug-for-bug compatible with the original. Signed-off-by: Paul E. McKenney Cc: Doug Ledford Cc: Jason Gunthorpe Cc: Richard Henderson Cc: Ivan Kokshaysky Cc: Matt Turner Cc: Michael Cree Cc: Andrea Parri Cc: Cc: --- drivers/dma/ioat/dma.c | 2 -- drivers/infiniba

Re: [PATCH tip/core/rcu 16/21] drivers/infiniband: Remove now-redundant smp_read_barrier_depends()

2017-12-01 Thread Paul E. McKenney
On Fri, Dec 01, 2017 at 05:11:09PM -0700, Jason Gunthorpe wrote: > On Fri, Dec 01, 2017 at 11:51:11AM -0800, Paul E. McKenney wrote: > > The smp_read_barrier_depends() does nothing at all except on DEC Alpha, > > and no current DEC Alpha systems use Infiniband: > > >

Re: [PATCH tip/core/rcu 16/21] drivers/infiniband: Remove now-redundant smp_read_barrier_depends()

2017-12-05 Thread Paul E. McKenney
On Tue, Dec 05, 2017 at 08:08:32AM -0700, Jason Gunthorpe wrote: > > commit c389c98ec5f4a7aa4c36853e89801eb5ea81870e > > Author: Paul E. McKenney > > Date: Mon Nov 27 09:04:22 2017 -0800 > > > > drivers/infiniband: Remove now-redundant smp_read_barrier_

Re: [PATCH] xchg/alpha: Add unconditional memory barrier to cmpxchg

2018-02-20 Thread Paul E. McKenney
gt; https://marc.info/?l=linux-kernel&m=151215810824468&w=2 > https://marc.info/?l=linux-kernel&m=151215816324484&w=2 > > [2] https://marc.info/?l=linux-kernel&m=151881978314872&w=2 > > Signed-off-by: Andrea Parri > Acked-by: Peter Zijlstra > Cc:

Re: [PATCH 1/2] locking/xchg/alpha: Use smp_mb() in place of __ASM__MB

2018-02-22 Thread Paul E. McKenney
gested-by: Will Deacon > Signed-off-by: Andrea Parri I am a bit confused by the use of out-of-line branches to do a backwards branch, but those were in place to start with. Maybe the point is to defeat backwards-branch prediction or some such. Regardless... Acked-by: Paul E. McKenney > Cc:

Re: [PATCH 2/2] locking/xchg/alpha: Add leading smp_mb() to xchg(), cmpxchg()

2018-02-22 Thread Paul E. McKenney
t; > WRITE_ONCE(x, 1) > > xchg(y, 1) > > > > smp_load_acquire(y) == 1 > > READ_ONCE(x) == 0 > > > > would be allowed. > > (thus violating the above requirement). Amend this by adding a > leading smp_mb() to the implementations of xchg(), cmpxchg(). > > Re

Re: [PATCH RFC 3/4] barriers: convert a control to a data dependency

2019-01-07 Thread Paul E. McKenney
On Mon, Jan 07, 2019 at 08:36:36AM -0500, Michael S. Tsirkin wrote: > On Mon, Jan 07, 2019 at 10:46:10AM +0100, Peter Zijlstra wrote: > > On Sun, Jan 06, 2019 at 11:23:07PM -0500, Michael S. Tsirkin wrote: > > > On Mon, Jan 07, 2019 at 11:58:23AM +0800, Jason Wang wrote: > > > > On 2019/1/3 上午4:57,

Re: [PATCH RFC 3/4] barriers: convert a control to a data dependency

2019-01-07 Thread Paul E. McKenney
On Mon, Jan 07, 2019 at 02:13:29PM -0500, Michael S. Tsirkin wrote: > On Mon, Jan 07, 2019 at 11:02:36AM -0800, Paul E. McKenney wrote: > > On Mon, Jan 07, 2019 at 08:36:36AM -0500, Michael S. Tsirkin wrote: > > > On Mon, Jan 07, 2019 at 10:46:10AM +0100, Peter Zijlstra wrote: &

[tip:core/rcu] drivers/infiniband: Remove now-redundant smp_read_barrier_depends()

2018-01-03 Thread tip-bot for Paul E. McKenney
Commit-ID: adf90eb49055636fc35aede54174456ac3520f27 Gitweb: https://git.kernel.org/tip/adf90eb49055636fc35aede54174456ac3520f27 Author: Paul E. McKenney AuthorDate: Mon, 27 Nov 2017 09:04:22 -0800 Committer: Paul E. McKenney CommitDate: Tue, 5 Dec 2017 11:56:54 -0800 drivers