Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1661108

Re: [PATCH 2/3] mm/page_ref: Ensure page_ref_unfreeze is ordered against prior accesses

Show all headers | View raw

On Thu, Jun 08, 2017 at 02:16:41PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 08, 2017 at 12:24:33PM +0100, Will Deacon wrote:

> > The horribly out-of-date atomic_ops.txt isn't so useful:
> > 
> > | If a caller requires memory barrier semantics around an atomic_t
> > | operation which does not return a value, a set of interfaces are
> > | defined which accomplish this::
> > | 
> > | 	void smp_mb__before_atomic(void);
> > | 	void smp_mb__after_atomic(void);
> > | 
> > | For example, smp_mb__before_atomic() can be used like so::
> > | 
> > | 	obj->dead = 1;
> > | 	smp_mb__before_atomic();
> > | 	atomic_dec(&obj->ref_count);
> > | 
> > | It makes sure that all memory operations preceding the atomic_dec()
> > | call are strongly ordered with respect to the atomic counter
> > | operation.  In the above example, it guarantees that the assignment of
> > | "1" to obj->dead will be globally visible to other cpus before the
> > | atomic counter decrement.
> > | 
> > | Without the explicit smp_mb__before_atomic() call, the
> > | implementation could legally allow the atomic counter update visible
> > | to other cpus before the "obj->dead = 1;" assignment.
> > 
> > which makes it sound more like the barrier is ordering all prior accesses
> > against the atomic operation itself (without going near cumulativity...),
> > and not with respect to anything later in program order.
> 
> This is correct.

Ah, my bad, It orders against everything later, the first of which is
(obviously) the atomic op itself.

It being a full barrier means both the Read and the Write of the RmW
must happen _after_ everything preceding.

> > Anyway, I think that's sufficient for what we want here, but we should
> > probably iron out the semantics of this thing.
> 
> s/smp_mb__\(before\|after\)_atomic/smp_mb/g
> 
> should not change the semantics of the code in _any_ way, just make it
> slower on architectures that already have SC atomic primitives (like
> x86).
> 

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [PATCH 2/3] mm/page_ref: Ensure page_ref_unfreeze is ordered  against prior accesses Vlastimil Babka <vbabka@suse.cz> - 2017-06-08 11:40 +0200
  Re: [PATCH 2/3] mm/page_ref: Ensure page_ref_unfreeze is ordered  against prior accesses Will Deacon <will.deacon@arm.com> - 2017-06-08 12:40 +0200
    Re: [PATCH 2/3] mm/page_ref: Ensure page_ref_unfreeze is ordered  against prior accesses Vlastimil Babka <vbabka@suse.cz> - 2017-06-08 13:10 +0200
  Re: [PATCH 2/3] mm/page_ref: Ensure page_ref_unfreeze is ordered  against prior accesses "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-06-08 12:50 +0200
    Re: [PATCH 2/3] mm/page_ref: Ensure page_ref_unfreeze is ordered  against prior accesses Vlastimil Babka <vbabka@suse.cz> - 2017-06-08 13:10 +0200
      Re: [PATCH 2/3] mm/page_ref: Ensure page_ref_unfreeze is ordered  against prior accesses Will Deacon <will.deacon@arm.com> - 2017-06-08 13:30 +0200
        Re: [PATCH 2/3] mm/page_ref: Ensure page_ref_unfreeze is ordered  against prior accesses Peter Zijlstra <peterz@infradead.org> - 2017-06-08 14:20 +0200
          Re: [PATCH 2/3] mm/page_ref: Ensure page_ref_unfreeze is ordered  against prior accesses Peter Zijlstra <peterz@infradead.org> - 2017-06-08 14:30 +0200
        Re: [PATCH 2/3] mm/page_ref: Ensure page_ref_unfreeze is ordered  against prior accesses Peter Zijlstra <peterz@infradead.org> - 2017-06-08 15:00 +0200
          Re: [PATCH 2/3] mm/page_ref: Ensure page_ref_unfreeze is ordered  against prior accesses Will Deacon <will.deacon@arm.com> - 2017-06-09 12:10 +0200

csiph-web