Messages in this thread | | | Date | Mon, 15 May 2017 02:19:55 -0700 | From | Davidlohr Bueso <> | Subject | Re: [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
| |