Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1641464
| From | Davidlohr Bueso <dave@stgolabs.net> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2 -tip 0/6] locking: Introduce range reader/writer lock |
| Date | 2017-05-15 11:30 +0200 |
| Message-ID | <tHkue-6eH-9@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <txX3Q-3sb-9@gated-at.bofh.it> <tynUl-3h3-9@gated-at.bofh.it> <tyox4-3vH-21@gated-at.bofh.it> <typ9M-3Yq-19@gated-at.bofh.it> <typMu-4rW-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next | Find similar | Unroll thread
Re: [PATCH v2 -tip 0/6] locking: Introduce range reader/writer lock Davidlohr Bueso <dave@stgolabs.net> - 2017-05-15 11:30 +0200
csiph-web