[lkml]   [2018]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] doc: rcu: remove note on smp_mb during synchronize_rcu
    Hi Paul,

    On Tue, Oct 30, 2018 at 04:43:36PM -0700, Paul E. McKenney wrote:
    > On Tue, Oct 30, 2018 at 03:26:49PM -0700, Joel Fernandes wrote:
    > > Hi Paul,
    > >
    > > On Sat, Oct 27, 2018 at 09:30:46PM -0700, Joel Fernandes (Google) wrote:
    > > > As per this thread [1], it seems this smp_mb isn't needed anymore:
    > > > "So the smp_mb() that I was trying to add doesn't need to be there."
    > > >
    > > > So let us remove this part from the memory ordering documentation.
    > > >
    > > > [1]
    > > >
    > > > Signed-off-by: Joel Fernandes (Google) <>
    > >
    > > I was just checking about this patch. Do you feel it is correct to remove
    > > this part from the docs? Are you satisified that a barrier isn't needed there
    > > now? Or did I miss something?
    > Apologies, it got lost in the shuffle. I have now applied it with a
    > bit of rework to the commit log, thank you!

    No worries, thanks for taking it!

    Just wanted to update you on my progress reading/correcting the docs. The
    'Memory Ordering' is taking a bit of time so I paused that and I'm focusing
    on finishing all the other low hanging fruit. This activity is mostly during
    night hours after the baby is asleep but some times I also manage to sneak it
    into the day job ;-)

    BTW I do want to discuss about this smp_mb patch above with you at LPC if you
    had time, even though we are removing it from the documentation. I thought
    about it a few times, and I was not able to fully appreciate the need for the
    barrier (that is even assuming that complete() etc did not do the right
    thing). Specifically I was wondering same thing Peter said in the above
    thread I think that - if that rcu_read_unlock() triggered all the spin
    locking up the tree of nodes, then why is that locking not sufficient to
    prevent reads from the read-side section from bleeding out? That would
    prevent the reader that just unlocked from seeing anything that happens
    _after_ the synchronize_rcu.

    Also about GP memory ordering and RCU-tree-locking, I think you mentioned to
    me that the RCU reader-sections are virtually extended both forward and
    backward and whereever it ends, those paths do heavy-weight synchronization
    that should be sufficient to prevent memory ordering issues (such as those
    you mentioned in the Requierments document). That is exactly why we don't
    need explicit barriers during rcu_read_unlock. If I recall I asked you why
    those are not needed. So that answer made sense, but then now on going
    through the 'Memory Ordering' document, I see that you mentioned there is
    reliance on the locking. Is that reliance on locking necessary to maintain
    ordering then?

    Or did I miss the points completely? :(

    TODO list of the index file marking which ones I have finished perusing:

    arrayRCU.txt DONE
    checklist.txt DONE
    listRCU.txt DONE
    lockdep.txt DONE
    lockdep-splat.txt DONE
    RTFP.txt DONE
    stallwarn.txt DONE
    whatisRCU.txt DONE

    - Data-Structures DONE
    - Requirements DONE
    - Expedited-Grace-Periods
    - Memory Ordering next

     \ /
      Last update: 2018-10-31 02:11    [W:4.283 / U:0.096 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site