Messages in this thread | | | Date | Thu, 09 Aug 2012 12:11:51 -0700 | From | John Stultz <> | Subject | Re: [PATCH 1/5] [RFC] Add volatile range management code |
| |
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
| |