lkml.org 
[lkml]   [2017]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH RFC tip/core/rcu 12/15] lib/assoc_array: Remove smp_read_barrier_depends()
Date
Will Deacon <will.deacon@arm.com> wrote:

> FWIW, that's exactly what my patches do, this fixup looks a bit weird
> because it removes a prior barrier which suggests that either (a) it's in
> the wrong place to start with, or (b) we're annotating the wrong load.

There is a loop involved. The barrier is against the read in the previous
iteration of the loop. IIRC, the reason I did it this way is to avoid the
need for the barrier if there's nothing on the 'after-side' - ie. we examine
the pointer and see that it's NULL or a leaf. However, I'm not sure that's a
particularly necessary optimisation.

So if READ_ONCE() issues a smp_read_barrier_depends() after the read, then
I've no problem with the removal of these explicit barriers.

I will, however, quibble with the appropriateness of the name READ_ONCE()...
I still think it's not sufficiently obvious that this is a barrier and the
barrier is after. Maybe READ_AND_BARRIER()?

Also, does WRITE_ONCE() imply a preceding barrier?

David

\
 
 \ /
  Last update: 2017-10-11 17:18    [W:0.135 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site