All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Dufour <ldufour@linux.vnet.ibm.com>
To: Davidlohr Bueso <dave@stgolabs.net>,
	mingo@kernel.org, peterz@infradead.org,
	akpm@linux-foundation.org
Cc: jack@suse.cz, kirill.shutemov@linux.intel.com, mhocko@suse.com,
	mgorman@techsingularity.net, linux-kernel@vger.kernel.org,
	Davidlohr Bueso <dbueso@suse.de>
Subject: Re: [PATCH 2/6] locking: Introduce range reader/writer lock
Date: Tue, 23 May 2017 17:12:45 +0200	[thread overview]
Message-ID: <7f35e628-1331-84df-5e1d-8c46233dbc6c@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170515090725.27055-3-dave@stgolabs.net>

On 15/05/2017 11:07, Davidlohr Bueso wrote:
> --- /dev/null
> +++ b/include/linux/range_lock.h
> @@ -0,0 +1,181 @@
> +/*
> + * Range/interval rw-locking
> + * -------------------------
> + *
> + * Interval-tree based range locking is about controlling tasks' forward
> + * progress when adding an arbitrary interval (node) to the tree, depending
> + * on any overlapping ranges. A task can only continue (wakeup) if there are
> + * no intersecting ranges, thus achieving mutual exclusion. To this end, a
> + * reference counter is kept for each intersecting range in the tree
> + * (_before_ adding itself to it). To enable shared locking semantics,
> + * the reader to-be-locked will not take reference if an intersecting node
> + * is also a reader, therefore ignoring the node altogether.
> + *
> + * Fairness and freedom of starvation are guaranteed by the lack of lock
> + * stealing, thus range locks depend directly on interval tree semantics.
> + * This is particularly for iterations, where the key for the rbtree is
> + * given by the interval's low endpoint, and duplicates are walked as it
> + * would an inorder traversal of the tree.
> + *
> + * The cost of lock and unlock of a range is O((1+R_int)log(R_all)) where
> + * R_all is total number of ranges and R_int is the number of ranges
> + * intersecting the operated range.
> + */
> +#ifndef _LINUX_RANGE_LOCK_H
> +#define _LINUX_RANGE_LOCK_H
> +
> +#include <linux/rbtree.h>
> +#include <linux/interval_tree.h>
> +#include <linux/list.h>
> +#include <linux/spinlock.h>
> +
> +/*
> + * The largest range will span [0,RANGE_LOCK_FULL].
> + */
> +#define RANGE_LOCK_FULL  ~0UL
> +
> +struct range_lock {
> +	struct interval_tree_node node;
> +	struct task_struct *tsk;
> +	/* Number of ranges which are blocking acquisition of the lock */
> +	unsigned int blocking_ranges;
> +	u64 seqnum;
> +};
> +
> +struct range_lock_tree {
> +	struct rb_root root;
> +	spinlock_t lock;
> +	struct interval_tree_node *leftmost; /* compute smallest 'start' */
> +	u64 seqnum; /* track order of incoming ranges, avoid overflows */
> +#ifdef CONFIG_DEBUG_LOCK_ALLOC
> +	struct lockdep_map dep_map;
> +#endif
> +};
> +
> +#ifdef CONFIG_DEBUG_LOCK_ALLOC
> +# define __RANGE_LOCK_DEP_MAP_INIT(lockname) , .dep_map = { .name = #lockname }
> +#else
> +# define __RANGE_LOCK_DEP_MAP_INIT(lockname)
> +#endif
> +
> +#define __RANGE_LOCK_TREE_INITIALIZER(name)		\
> +	{ .leftmost = NULL                              \
> +	, .root = RB_ROOT				\
> +	, .seqnum = 0					\
> +	, .lock = __SPIN_LOCK_UNLOCKED(name.lock)       \
> +	__RANGE_LOCK_DEP_MAP_INIT(name) }		\
> +
> +#define DEFINE_RANGE_LOCK_TREE(name) \
> +	struct range_lock_tree name = __RANGE_LOCK_TREE_INITIALIZER(name)
> +
> +#define __RANGE_LOCK_INITIALIZER(__start, __last) {	\
> +		.node = {				\
> +			.start = (__start)		\
> +			,.last = (__last)		\
> +		}					\
> +		, .task = NULL				\
                   ^tsk

> +		, .blocking_ranges = 0			\
> +		, .reader = false			\
                   ^ this field doesn't exist anymore

Cheers,
Laurent.

  parent reply	other threads:[~2017-05-23 15:12 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-15  9:07 [PATCH v3 -tip 0/6] locking: Introduce range reader/writer lock Davidlohr Bueso
2017-05-15  9:07 ` [PATCH 1/6] interval-tree: Build unconditionally Davidlohr Bueso
2017-05-15  9:07 ` [PATCH 2/6] locking: Introduce range reader/writer lock Davidlohr Bueso
2017-05-15 13:02   ` Peter Zijlstra
2017-05-16 22:19     ` Davidlohr Bueso
2017-05-15 13:44   ` Peter Zijlstra
2017-05-16 21:17     ` Davidlohr Bueso
2017-05-15 13:59   ` Peter Zijlstra
2017-05-23 15:12   ` Laurent Dufour [this message]
2017-05-15  9:07 ` [PATCH 3/6] locking/locktorture: Fix rwsem reader_delay Davidlohr Bueso
2017-05-15  9:07 ` [PATCH 4/6] locking/locktorture: Fix num reader/writer corner cases Davidlohr Bueso
2017-05-15  9:07 ` [PATCH 5/6] locking/locktorture: Support range rwlocks Davidlohr Bueso
2017-05-15  9:07 ` [PATCH 6/6] staging/lustre: Use generic range rwlock Davidlohr Bueso
2017-05-18  8:30   ` Dilger, Andreas
2017-05-18  8:30     ` [lustre-devel] " Dilger, Andreas
2017-05-15 16:11 ` [PATCH v3 -tip 0/6] locking: Introduce range reader/writer lock Christoph Hellwig
2017-06-08 16:22 ` Davidlohr Bueso
  -- strict thread matches above, loose matches on Subject: below --
2017-04-06  8:46 [PATCH v2 " Davidlohr Bueso
2017-04-06  8:46 ` [PATCH 2/6] " Davidlohr Bueso
2017-04-06  9:01   ` Laurent Dufour
2017-04-06 16:50     ` Davidlohr Bueso
2017-04-13  8:07       ` Laurent Dufour
2017-04-13  8:38         ` Jan Kara
2017-04-13  8:58           ` Laurent Dufour
2017-04-06 10:24   ` Peter Zijlstra
2017-04-18 13:57   ` Laurent Dufour
2017-04-20 16:01     ` Davidlohr Bueso
2017-04-21  7:00       ` Laurent Dufour

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7f35e628-1331-84df-5e1d-8c46233dbc6c@linux.vnet.ibm.com \
    --to=ldufour@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave@stgolabs.net \
    --cc=dbueso@suse.de \
    --cc=jack@suse.cz \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@suse.com \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.