Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1641464 > unrolled thread
| Started by | Davidlohr Bueso <dave@stgolabs.net> |
|---|---|
| First post | 2017-05-15 11:30 +0200 |
| Last post | 2017-05-15 11:30 +0200 |
| Articles | 1 — 1 participant |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v2 -tip 0/6] locking: Introduce range reader/writer lock Davidlohr Bueso <dave@stgolabs.net> - 2017-05-15 11:30 +0200
| From | Davidlohr Bueso <dave@stgolabs.net> |
|---|---|
| Date | 2017-05-15 11:30 +0200 |
| Subject | Re: [PATCH v2 -tip 0/6] locking: Introduce range reader/writer lock |
| Message-ID | <tHkue-6eH-9@gated-at.bofh.it> |
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 top | Article view | linux.kernel
csiph-web