On 06/26/2012 09:45 AM, Peter Zijlstra wrote:
On Tue, 2012-06-26 at 09:05 -0400, Rik van Riel wrote:
On 06/26/2012 04:31 AM, Peter Zijlstra wrote:
If you look at your patch 1, __vma_unlink has an adjust_free_gap() right
next to the rb_augment_erase(), vma_adjust() has 3 adjust_free_gap()
calls right next to each other.
All these will do an entire path walk back to the root. I would think we
could save quite a bit of updating by not having them all walk back to
the root. No point in re-computing the top levels if you know the next
update will change them again anyway.
The problem is, unless we look at the augmented data at
rotate time, we do not know when it is safe to stop
iterating up the tree.
argh,.. you're using adjust_vma_gap() for insertions instead of
rb_augment_insert().
I was going on the premise that you're doing updates for augmented data
without modifying the tree structure and that doing insert/delete will
keep the stuff up-to-date.
So now I'm not sure why you do if (insert) adjust_free_gap(insert),
since __insert_vm_struct(mm, insert) -> __vma_link() -> __vma_link_rb()
already does an augment update.
I have fixed that in patch 3/11 of this series,
which I kept separate for this round of submission
to make it easier for reviewers to see what I
changed there.
However, doing an insert or delete changes the
gap size for the _next_ vma, and potentially a
change in the maximum gap size for the parent
node, so both insert and delete cause two tree
walks :(
--
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>