lkml.org 
[lkml]   [2017]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 -tip 0/6] locking: Introduce range reader/writer lock
    On Thu, 20 Apr 2017, Peter Zijlstra wrote:

    >For opt spinning we need to specifically know who would be next in
    >order, again, doesn't matter how many, just who's next.

    I've sent a v3 with a more precise description of this, which I hope is
    to your satisfaction.

    Given a clear tree iteration/order defined by interval trees (indexed by
    lowpoint and treats duplicates as inorder traversal), it is not something
    I would wish to alter. Over the weekend I've been experimenting more with
    still taking the tree->lock, but spinning while blocking ranges is 1 and
    'owner' (in this case the first overlapping node, remembered when we did
    the initial lookup adding to the tree, _with_ the tree->lock held) is on_cpu.
    This would maintain the order and prevent blocking for threads that are
    about (?) to receive the lock.

    While I have somewhat of a patch, I'm tired and have not had the chance to
    even test the thing, so I went ahead and sent v3 anyway to not delay further.

    Thanks,
    Davidlohr

    \
     
     \ /
      Last update: 2017-05-15 11:20    [W:2.831 / U:0.140 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site