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

Groups > linux.kernel > #1626065 > unrolled thread

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

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.

Contents

  Re: [PATCH v2 -tip 0/6] locking: Introduce range reader/writer lock Peter Zijlstra <peterz@infradead.org> - 2017-04-19 14:40 +0200
    Re: [PATCH v2 -tip 0/6] locking: Introduce range reader/writer lock Davidlohr Bueso <dave@stgolabs.net> - 2017-04-20 19:20 +0200
      Re: [PATCH v2 -tip 0/6] locking: Introduce range reader/writer lock Peter Zijlstra <peterz@infradead.org> - 2017-04-20 20:00 +0200
        Re: [PATCH v2 -tip 0/6] locking: Introduce range reader/writer lock Davidlohr Bueso <dave@stgolabs.net> - 2017-04-20 20:40 +0200
          Re: [PATCH v2 -tip 0/6] locking: Introduce range reader/writer lock Peter Zijlstra <peterz@infradead.org> - 2017-04-20 21:20 +0200

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

On Thu, Apr 06, 2017 at 01:46:14AM -0700, Davidlohr Bueso wrote:
> ** What's still pending:
>   - Debug support (it's been a pain to use lockdep with range locking).

How so? Just assume that every range is the full range. Which isn't such
a weird assumption as it would seem. After all, you cannot assume
anything much about the ranges to begin with. So therefore you cannot
assume the ranges don't all overlap either. At which point you're back
to the regular r/w semantics for deadlocks.

Also:

  - explain interval order and what that means for forward progress
    guarantees. This is currently still unparsable.

  - explain why the loss of lock stealing makes sense. IIRC walken added
    that specifically to address mmap_sem performance issues.

[toc] | [next] | [standalone]

#1627687

On Wed, 19 Apr 2017, Peter Zijlstra wrote:

>  - explain why the loss of lock stealing makes sense. IIRC walken added
>    that specifically to address mmap_sem performance issues.

That's right, and the same applies to the writer spinning stuff; which
can makes a huge difference - more so than plain stealing. But as I've
mentioned, range locks can improve parallelism, which is/should be much
more welcomed than optimizations to the primitive. So yeah, we loose 
in comparing a full range to rwsem (not to mention the xadd stuff).
I have thought of some heuristics for avoiding sleeping under certain
constraints, which could mitigate the spinning step we loose, but 
I fear it will never be exactly as fast as rwsems -- just consider
we always take the tree->lock.

Thanks,
Davidlohr

[toc] | [prev] | [next] | [standalone]

#1627725

On Thu, Apr 20, 2017 at 10:13:26AM -0700, Davidlohr Bueso wrote:

> I have thought of some heuristics for avoiding sleeping under certain
> constraints, which could mitigate the spinning step we loose, but I fear it
> will never be exactly as fast as rwsems -- just consider
> we always take the tree->lock.

But tree->lock is a spinlock, so while this gets us out of rwsem-xadd
territory for the fast paths, the whole lock-stealing and optimistic
spinning stuff is on a different scale.

Those are about avoiding actually going to sleep and having to be woken
up (and waiting to become running) again, which is a long time.

[toc] | [prev] | [next] | [standalone]

#1627740

On Thu, 20 Apr 2017, Peter Zijlstra wrote:

>On Thu, Apr 20, 2017 at 10:13:26AM -0700, Davidlohr Bueso wrote:
>
>> I have thought of some heuristics for avoiding sleeping under certain
>> constraints, which could mitigate the spinning step we loose, but I fear it
>> will never be exactly as fast as rwsems -- just consider
>> we always take the tree->lock.
>
>But tree->lock is a spinlock, so while this gets us out of rwsem-xadd
>territory for the fast paths, the whole lock-stealing and optimistic
>spinning stuff is on a different scale.

Oh, absolutely. I was merely pointing out the differences at a hair
splitting level.

>Those are about avoiding actually going to sleep and having to be woken
>up (and waiting to become running) again, which is a long time.

Yes, which is why I was thinking of ways to mitigate this. Ie: for
blocked writers with low counts of 'blocking_ranges'.

Thanks,
Davidlohr

[toc] | [prev] | [next] | [standalone]

#1627755

On Thu, Apr 20, 2017 at 11:36:46AM -0700, Davidlohr Bueso wrote:
> On Thu, 20 Apr 2017, Peter Zijlstra wrote:
> >Those are about avoiding actually going to sleep and having to be woken
> >up (and waiting to become running) again, which is a long time.
> 
> Yes, which is why I was thinking of ways to mitigate this. Ie: for
> blocked writers with low counts of 'blocking_ranges'.

So for this it would be good to have a better understanding of that
whole fairness / interval order crud.

IIRC rwsem only does writer-writer stealing and opt spinning, right? And
for stealing it doesn't matter how many are pending, just that you are
running and they are not (and then you get fairness issues and handover
etc..).

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web