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


Groups > linux.kernel > #1617848

Re: [PATCH 2/6] locking: Introduce range reader/writer lock

From Peter Zijlstra <peterz@infradead.org>
Newsgroups linux.kernel
Subject Re: [PATCH 2/6] locking: Introduce range reader/writer lock
Date 2017-04-06 12:30 +0200
Message-ID <ttcPV-7fO-37@gated-at.bofh.it> (permalink)
References <ttbh9-6aP-61@gated-at.bofh.it> <ttbqO-6ei-37@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, Apr 06, 2017 at 01:46:16AM -0700, Davidlohr Bueso wrote:
> +/*
> + * Range/interval rw-locking
> + * -------------------------
> + *
> + * An interval tree of locked and to-be-locked ranges is kept. When a new range
> + * lock is requested, we add its interval to the tree and store number of
> + * intervals intersecting it to 'blocking_ranges'.

You're again confusing semantics with implementation here.

> For the reader case,
> + * 'blocking_ranges' is only accounted for if the intersecting range is
> + * marked as a writer. To achieve mutual exclusion of arbitrary ranges, we
> + * guarantee that task is blocked until there are no overlapping ranges in the
> + * tree.
> + *
> + * When a range is unlocked, we again walk intervals that overlap with the
> + * unlocked one and decrement their 'blocking_ranges'. Naturally, we wake up
> + * owner of any range lock whose 'blocking_ranges' drops to 0. Wakeup order
> + * therefore relies on the order of the interval tree  -- as opposed to a
> + * more traditional fifo mechanism.

Which order is that? (I could of course go read the interval tree code,
but it shouldn't be too much effort to mention it here).

> There is no lock stealing either, which
> + * prevents starvation and guarantees fairness.

So no lock stealing has always been very bad for performance. So are you
sure people will not frob this back in?


> +#ifndef _LINUX_RANGE_RWLOCK_H

Still don't like the name... rwlock_t is a spinlock.

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

[PATCH v2 -tip 0/6] locking: Introduce range reader/writer lock Davidlohr Bueso <dave@stgolabs.net> - 2017-04-06 11:00 +0200
  [PATCH 6/6] staging/lustre: Use generic range rwlock Davidlohr Bueso <dave@stgolabs.net> - 2017-04-06 11:00 +0200
    Re: [PATCH 6/6] staging/lustre: Use generic range rwlock "Dilger, Andreas" <andreas.dilger@intel.com> - 2017-04-07 12:10 +0200
  [PATCH 4/6] locking/locktorture: Fix num reader/writer corner cases Davidlohr Bueso <dave@stgolabs.net> - 2017-04-06 11:00 +0200
  [PATCH 1/6] interval-tree: Build unconditionally Davidlohr Bueso <dave@stgolabs.net> - 2017-04-06 11:00 +0200
  [PATCH 2/6] locking: Introduce range reader/writer lock Davidlohr Bueso <dave@stgolabs.net> - 2017-04-06 11:00 +0200
    Re: [PATCH 2/6] locking: Introduce range reader/writer lock Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2017-04-06 11:10 +0200
      Re: [PATCH 2/6] locking: Introduce range reader/writer lock Davidlohr Bueso <dave@stgolabs.net> - 2017-04-06 19:00 +0200
    Re: [PATCH 2/6] locking: Introduce range reader/writer lock Peter Zijlstra <peterz@infradead.org> - 2017-04-06 12:30 +0200

csiph-web