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

[John Stultz]

On 08/09/2012 02:46 AM, Michel Lespinasse wrote:
> On Fri, Jul 27, 2012 at 8:57 PM, John Stultz <john.stultz@xxxxxxxxxx> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/