Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1641464

Re: [PATCH v2 -tip 0/6] locking: Introduce range reader/writer lock

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

Show all headers | View raw


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


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