Re: [PATCH 1/5] [RFC] Add volatile range management code

John Stultz
2012-08-09T19:14:23Z

On 08/09/2012 02:46 AM, Michel Lespinasse wrote:
> On Fri, Jul 27, 2012 at 8:57 PM, John Stultz <john.stultz@linaro.org> wrote:
>> v5:
>> * Drop intervaltree for prio_tree usage per Michel &
>> Dmitry's suggestions.
> Actually, I believe the ranges you need to track are non-overlapping, correct ?
Correct. Any overlapping range is coalesced.

> If that is the case, a simple rbtree, sorted by start-of-range
> address, would work best.
> (I am trying to remove prio_tree users... :)

Sigh. Sure. Although I've blown with the wind on a number of different
approaches for storing the ranges. I'm not particularly passionate about
it, but the continual conflicting suggestions are a slight frustration. :)

>> + /* First, find any existing intervals that overlap */
>> + prio_tree_iter_init(&iter, root, start, end);
> Note that prio tree iterations take intervals as [start; last] not [start; end[
> So if you want to stick with prio trees, you would have to use end-1 here.
Thanks! I think I hit this off-by-one issue in my testing, but fixed it
on the backend w/ :

modify_range(&inode->i_data, start, end-1, &mark_nonvolatile_page);

Clearly fixing it at the start instead of papering over it is better.

>> + node = prio_tree_next(&iter);
>> + while (node) {
> I'm confused, I don't think you ever expect more than one range to
> match, do you ???

So yea. If you already have two ranges (0-5),(10-15) and then add range
(0-20) we need to coalesce the two existing ranges into the new one.

> This is far from a complete code review, but I just wanted to point
> out a couple details that jumped to me first. I am afraid I am missing
> some of the background about how the feature is to be used to really
> dig into the rest of the changes at this point :/

Well, I really appreciate any feedback here.

thanks
-john