public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: Jan Kara <jack@suse.cz>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Android Kernel Team <kernel-team@android.com>,
	Robert Love <rlove@google.com>, Mel Gorman <mel@csn.ul.ie>,
	Hugh Dickins <hughd@google.com>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Rik van Riel <riel@redhat.com>,
	Dmitry Adamushko <dmitry.adamushko@gmail.com>,
	Dave Chinner <david@fromorbit.com>, Neil Brown <neilb@suse.de>,
	Andrea Righi <andrea@betterlinux.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Taras Glek <tgek@mozilla.com>, Mike Hommey <mh@glandium.org>
Subject: Re: [PATCH 2/4] [RFC] Range tree implementation
Date: Thu, 31 May 2012 14:04:23 -0700	[thread overview]
Message-ID: <4FC7DCD7.6020800@linaro.org> (raw)
In-Reply-To: <20120531204806.GB16338@quack.suse.cz>

On 05/31/2012 01:48 PM, Jan Kara wrote:
> On Fri 25-05-12 12:17:34, John Stultz wrote:
>> I suspect range-tree isn't a totally accurate name, but I
>> couldn't quite make out the difference between range trees
>> and interval trees, so I just picked one to call it. Do
>> let me know if you have a better name.
>    Well, interval tree is a data structure for tracking a set of
> possibly overlapping intervals. Range tree is a data structure tracking
> points allowing for fast queries on a set of points contained in a given
> range (gets useful and interesting when dimension>  1). Your data structure
> is neither so it would be good to have a different name. OTOH there are so
> many data structures that it's hard to find a reasonable unused name ;)

Although I'm not sure your interval tree description doesn't match what 
I'm trying to provide. Could you clarify why that doesn't match?

>> +/**
>> + * range_tree_next_in_range - Return the next range in a range_tree still
>> + *                            contained within a specified range.
>    'within' isn't really correct, right? It should rather be 'intersecting'.

That is more clear, thanks for the suggestion!

>
>> + * @root: range_tree root
>> + * @start: range start
>> + * @end: range end
>> + *
>> + */
>> +struct range_tree_node *range_tree_next_in_range(struct range_tree_node *node,
>> +							u64 start, u64 end)
>> +{
>> +	struct rb_node *next;
>> +	struct range_tree_node *candidate;
>> +	if (!node)
>> +		return NULL;
>> +	next = rb_next(&node->rb);
>> +	if (!next)
>> +		return NULL;
>> +
>> +	candidate = container_of(next, struct range_tree_node, rb);
>> +
>> +	if ((candidate->start>  end) || (candidate->end<  start))
>> +		return NULL;
>> +
>> +	return candidate;
>> +}
>> +
>> +/**
>> + * range_tree_add - Add a node to a range tree
>> + * @root: range tree to be added to
>> + * @node: range_tree_node to be added
>> + *
>> + * Adds a node to the range tree.
>    I think you should document here that the added range must not intersect
> with any other range in the tree.

So for my usage in the volatile range code, I don't want intersecting or 
overlapping ranges added, but I didn't feel it was necessary to add this 
restriction to my rangetree code as well, since someone might want to 
store overlapping ranges.

thanks for the review!
-john



  reply	other threads:[~2012-05-31 21:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-25 19:17 [PATCH 0/4] [RFC] Fallocate Volatile Ranges John Stultz
2012-05-25 19:17 ` [PATCH 1/4] tmpfs: support fallocate FALLOC_FL_PUNCH_HOLE John Stultz
2012-05-25 19:17 ` [PATCH 2/4] [RFC] Range tree implementation John Stultz
2012-05-31 20:48   ` Jan Kara
2012-05-31 21:04     ` John Stultz [this message]
2012-05-31 22:35       ` Jan Kara
2012-05-31 23:12         ` John Stultz
2012-05-25 19:17 ` [PATCH 3/4] [RFC] Add volatile range management code John Stultz
2012-05-25 19:17 ` [PATCH 4/4] [RFC] tmpfs: Add FALLOC_FL_MARK_VOLATILE/UNMARK_VOLATILE handlers John Stultz

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=4FC7DCD7.6020800@linaro.org \
    --to=john.stultz@linaro.org \
    --cc=akpm@linux-foundation.org \
    --cc=andrea@betterlinux.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=dave@linux.vnet.ibm.com \
    --cc=david@fromorbit.com \
    --cc=dmitry.adamushko@gmail.com \
    --cc=hughd@google.com \
    --cc=jack@suse.cz \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mel@csn.ul.ie \
    --cc=mh@glandium.org \
    --cc=neilb@suse.de \
    --cc=riel@redhat.com \
    --cc=rlove@google.com \
    --cc=tgek@mozilla.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox