On Tue, Sep 22, 2015 at 04:58:28PM +0100, Will Deacon wrote:
> Hi Paul,
>
> On Tue, Sep 22, 2015 at 04:22:41PM +0100, Paul E. McKenney wrote:
> > On Mon, Sep 21, 2015 at 11:23:01PM +0100, Will Deacon wrote:
> > > On Mon, Sep 21, 2015 at 03:10:38PM +0100, Boqun Feng wrote:
> > > > On Mon, Sep 21, 2
Hi Paul,
On Tue, Sep 22, 2015 at 04:22:41PM +0100, Paul E. McKenney wrote:
> On Mon, Sep 21, 2015 at 11:23:01PM +0100, Will Deacon wrote:
> > On Mon, Sep 21, 2015 at 03:10:38PM +0100, Boqun Feng wrote:
> > > On Mon, Sep 21, 2015 at 09:45:15PM +0800, Boqun Feng wrote:
> > > >
> > > > Ah.. that's i
On Mon, Sep 21, 2015 at 11:23:01PM +0100, Will Deacon wrote:
> On Mon, Sep 21, 2015 at 03:10:38PM +0100, Boqun Feng wrote:
> > On Mon, Sep 21, 2015 at 09:45:15PM +0800, Boqun Feng wrote:
> > > On Thu, Sep 17, 2015 at 07:00:01PM +0100, Will Deacon wrote:
> > > > On Thu, Sep 17, 2015 at 03:50:12AM +0
On Mon, Sep 21, 2015 at 11:23:01PM +0100, Will Deacon wrote:
> On Mon, Sep 21, 2015 at 03:10:38PM +0100, Boqun Feng wrote:
> > On Mon, Sep 21, 2015 at 09:45:15PM +0800, Boqun Feng wrote:
> > > On Thu, Sep 17, 2015 at 07:00:01PM +0100, Will Deacon wrote:
> > > > On Thu, Sep 17, 2015 at 03:50:12AM +0
On Mon, Sep 21, 2015 at 03:10:38PM +0100, Boqun Feng wrote:
> On Mon, Sep 21, 2015 at 09:45:15PM +0800, Boqun Feng wrote:
> > On Thu, Sep 17, 2015 at 07:00:01PM +0100, Will Deacon wrote:
> > > On Thu, Sep 17, 2015 at 03:50:12AM +0100, Boqun Feng wrote:
> > > > If an ACQUIRE loads the value of store
On Mon, Sep 21, 2015 at 09:45:15PM +0800, Boqun Feng wrote:
> On Thu, Sep 17, 2015 at 07:00:01PM +0100, Will Deacon wrote:
> > On Thu, Sep 17, 2015 at 03:50:12AM +0100, Boqun Feng wrote:
> > > On Wed, Sep 16, 2015 at 12:07:06PM +0100, Will Deacon wrote:
> > > > On Wed, Sep 16, 2015 at 11:43:14AM +0
On Thu, Sep 17, 2015 at 07:00:01PM +0100, Will Deacon wrote:
> On Thu, Sep 17, 2015 at 03:50:12AM +0100, Boqun Feng wrote:
> > On Wed, Sep 16, 2015 at 12:07:06PM +0100, Will Deacon wrote:
> > > On Wed, Sep 16, 2015 at 11:43:14AM +0100, Peter Zijlstra wrote:
> > > > On Wed, Sep 16, 2015 at 11:29:08A
On Thu, Sep 17, 2015 at 03:50:12AM +0100, Boqun Feng wrote:
> On Wed, Sep 16, 2015 at 12:07:06PM +0100, Will Deacon wrote:
> > On Wed, Sep 16, 2015 at 11:43:14AM +0100, Peter Zijlstra wrote:
> > > On Wed, Sep 16, 2015 at 11:29:08AM +0100, Will Deacon wrote:
> > > > > Indeed, that is a hole in the d
On Thu, Sep 17, 2015 at 10:50:12AM +0800, Boqun Feng wrote:
> On Wed, Sep 16, 2015 at 12:07:06PM +0100, Will Deacon wrote:
> > On Wed, Sep 16, 2015 at 11:43:14AM +0100, Peter Zijlstra wrote:
> > > On Wed, Sep 16, 2015 at 11:29:08AM +0100, Will Deacon wrote:
> > > > > Indeed, that is a hole in the d
On Wed, Sep 16, 2015 at 12:07:06PM +0100, Will Deacon wrote:
> On Wed, Sep 16, 2015 at 11:43:14AM +0100, Peter Zijlstra wrote:
> > On Wed, Sep 16, 2015 at 11:29:08AM +0100, Will Deacon wrote:
> > > > Indeed, that is a hole in the definition, that I think we should close.
> >
> > > I'm struggling t
On Wed, Sep 16, 2015 at 05:38:14PM +0100, Will Deacon wrote:
> On Wed, Sep 16, 2015 at 12:49:18PM +0100, Boqun Feng wrote:
> > Hi Will,
>
> Hello,
>
> > On Tue, Sep 15, 2015 at 05:13:30PM +0100, Will Deacon wrote:
> > > +If necessary, ordering can be enforced by use of an
> > > +smp_mb__release_a
On Wed, Sep 16, 2015 at 12:49:18PM +0100, Boqun Feng wrote:
> Hi Will,
Hello,
> On Tue, Sep 15, 2015 at 05:13:30PM +0100, Will Deacon wrote:
> > +If necessary, ordering can be enforced by use of an
> > +smp_mb__release_acquire() barrier:
> > +
> > + *A = a;
> > + RELEASE M
> > + smp_mb__rel
Hi Will,
On Tue, Sep 15, 2015 at 05:13:30PM +0100, Will Deacon wrote:
> As much as we'd like to live in a world where RELEASE -> ACQUIRE is
> always cheaply ordered and can be used to construct UNLOCK -> LOCK
> definitions with similar guarantees, the grim reality is that this isn't
> even possibl
On Wed, Sep 16, 2015 at 11:43:14AM +0100, Peter Zijlstra wrote:
> On Wed, Sep 16, 2015 at 11:29:08AM +0100, Will Deacon wrote:
> > > Indeed, that is a hole in the definition, that I think we should close.
>
> > I'm struggling to understand the hole, but here's my intuition. If an
> > ACQUIRE on CP
On Wed, Sep 16, 2015 at 11:29:08AM +0100, Will Deacon wrote:
> > Indeed, that is a hole in the definition, that I think we should close.
> I'm struggling to understand the hole, but here's my intuition. If an
> ACQUIRE on CPUx reads from a RELEASE by CPUy, then I'd expect CPUx to
> observe all mem
Hi Paul, Peter,
Thanks for the comments. More below...
On Wed, Sep 16, 2015 at 10:14:52AM +0100, Peter Zijlstra wrote:
> On Tue, Sep 15, 2015 at 10:47:24AM -0700, Paul E. McKenney wrote:
> > > diff --git a/arch/powerpc/include/asm/barrier.h
> > > b/arch/powerpc/include/asm/barrier.h
> > > index
On Tue, Sep 15, 2015 at 10:47:24AM -0700, Paul E. McKenney wrote:
> > diff --git a/arch/powerpc/include/asm/barrier.h
> > b/arch/powerpc/include/asm/barrier.h
> > index 0eca6efc0631..919624634d0a 100644
> > --- a/arch/powerpc/include/asm/barrier.h
> > +++ b/arch/powerpc/include/asm/barrier.h
> > @
On Tue, Sep 15, 2015 at 05:13:30PM +0100, Will Deacon wrote:
> As much as we'd like to live in a world where RELEASE -> ACQUIRE is
> always cheaply ordered and can be used to construct UNLOCK -> LOCK
> definitions with similar guarantees, the grim reality is that this isn't
> even possible on x86 (
18 matches
Mail list logo
