lkml.org 
[lkml]   [2017]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [GIT PULL rcu/next] RCU commits for 4.13
    On Wed, Jun 28, 2017 at 4:54 PM, Paul E. McKenney
    <paulmck@linux.vnet.ibm.com> wrote:
    >
    > Linus, are you dead-set against defining spin_unlock_wait() to be
    > spin_lock + spin_unlock? For example, is the current x86 implementation
    > of spin_unlock_wait() really a non-negotiable hard requirement? Or
    > would you be willing to live with the spin_lock + spin_unlock semantics?

    So I think the "same as spin_lock + spin_unlock" semantics are kind of insane.

    One of the issues is that the same as "spin_lock + spin_unlock" is
    basically now architecture-dependent. Is it really the
    architecture-dependent ordering you want to define this as?

    So I just think it's a *bad* definition. If somebody wants something
    that is exactly equivalent to spin_lock+spin_unlock, then dammit, just
    do *THAT*. It's completely pointless to me to define
    spin_unlock_wait() in those terms.

    And if it's not equivalent to the *architecture* behavior of
    spin_lock+spin_unlock, then I think it should be descibed in terms
    that aren't about the architecture implementation (so you shouldn't
    describe it as "spin_lock+spin_unlock", you should describe it in
    terms of memory barrier semantics.

    And if we really have to use the spin_lock+spinunlock semantics for
    this, then what is the advantage of spin_unlock_wait at all, if it
    doesn't fundamentally avoid some locking overhead of just taking the
    spinlock in the first place?

    And if we can't use a cheaper model, maybe we should just get rid of
    it entirely?

    Finally: if the memory barrier semantics are exactly the same, and
    it's purely about avoiding some nasty contention case, I think the
    concept is broken - contention is almost never an actual issue, and if
    it is, the problem is much deeper than spin_unlock_wait().

    Linus

    \
     
     \ /
      Last update: 2017-06-29 02:06    [W:4.406 / U:0.484 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site