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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>