Re: [PATCH 1/3] x86,mm/pat: Use generic interval trees

2019-09-04 Thread Davidlohr Bueso
On Wed, 04 Sep 2019, Michel Lespinasse wrote: Hi Davidlohr, On Wed, Sep 4, 2019 at 5:52 PM Davidlohr Bueso wrote: Ok, so for that I've added the following helper which will make the conversion a bit more straightforward: #define vma_interval_tree_foreach_stab(vma, root, start)

Re: [PATCH 1/3] x86,mm/pat: Use generic interval trees

2019-09-04 Thread Davidlohr Bueso
On Wed, 04 Sep 2019, Michel Lespinasse wrote: I do not have time for a full review right now, but I did have a quick pass at it and it does seem to match the direction I'd like this to take. Thanks, and no worries, I consider all this v5.5 material anyway. Please let me know if you'd like

Re: [PATCH 1/3] x86,mm/pat: Use generic interval trees

2019-09-04 Thread Michel Lespinasse
Hi Davidlohr, On Wed, Sep 4, 2019 at 5:52 PM Davidlohr Bueso wrote: > Ok, so for that I've added the following helper which will make the > conversion a bit more straightforward: > > #define vma_interval_tree_foreach_stab(vma, root, start) >vma_interval_tree_foreach(vma, root, start,

Re: [PATCH 1/3] x86,mm/pat: Use generic interval trees

2019-09-04 Thread Davidlohr Bueso
On Thu, 22 Aug 2019, Michel Lespinasse wrote: I think vma_interval_tree is a bit of a mixed bag, but mostly leans towards using half closed intervals. Right now vma_last_pgoff() has to do -1 because of the interval tree using closed intervals. Similarly, rmap_walk_file(), which I consider to

Re: [PATCH 1/3] x86,mm/pat: Use generic interval trees

2019-08-22 Thread Michel Lespinasse
On Wed, Aug 21, 2019 at 9:49 PM Davidlohr Bueso wrote: > On Wed, 21 Aug 2019, Michel Lespinasse wrote: > >I'm not sure where to go with this - would it make sense to add a new > >interval tree header file that uses [start,end) intervals (with the > >thought of eventually converting all current

Re: [PATCH 1/3] x86,mm/pat: Use generic interval trees

2019-08-22 Thread Michel Lespinasse
I think vma_interval_tree is a bit of a mixed bag, but mostly leans towards using half closed intervals. Right now vma_last_pgoff() has to do -1 because of the interval tree using closed intervals. Similarly, rmap_walk_file(), which I consider to be the main user of the vma_interval_tree, also

Re: [PATCH 1/3] x86,mm/pat: Use generic interval trees

2019-08-22 Thread Davidlohr Bueso
On Wed, 21 Aug 2019, Michel Lespinasse wrote: As I had commented some time ago, I wish the interval trees used [start,end) intervals instead of [start,last] - it would be a better fit for basically all of the current interval tree users. So the vma_interval_tree (which is a pretty important

Re: [PATCH 1/3] x86,mm/pat: Use generic interval trees

2019-08-21 Thread Davidlohr Bueso
On Wed, 21 Aug 2019, Michel Lespinasse wrote: On Tue, Aug 13, 2019 at 03:46:18PM -0700, Davidlohr Bueso wrote: o The border cases for overlapping differ -- interval trees are closed, while memtype intervals are open. We need to maintain semantics such that conflict detection and getting the

Re: [PATCH 1/3] x86,mm/pat: Use generic interval trees

2019-08-21 Thread Michel Lespinasse
On Tue, Aug 13, 2019 at 03:46:18PM -0700, Davidlohr Bueso wrote: > o The border cases for overlapping differ -- interval trees are closed, > while memtype intervals are open. We need to maintain semantics such > that conflict detection and getting the lowest match does not change. Agree on the

Re: [PATCH 1/3] x86,mm/pat: Use generic interval trees

2019-08-21 Thread Peter Zijlstra
On Tue, Aug 13, 2019 at 03:46:18PM -0700, Davidlohr Bueso wrote: > diff --git a/arch/x86/mm/pat_rbtree.c b/arch/x86/mm/pat_rbtree.c > index fa16036fa592..1be4d1856a9b 100644 > --- a/arch/x86/mm/pat_rbtree.c > +++ b/arch/x86/mm/pat_rbtree.c > @@ -34,68 +34,41 @@ > * memtype_lock protects the

[PATCH 1/3] x86,mm/pat: Use generic interval trees

2019-08-13 Thread Davidlohr Bueso
With some considerations, the custom pat_rbtree implementation can be simplified to use most of the generic interval_tree machinery. o The tree inorder traversal can slightly differ when there are key ('start') collisions in the tree due to one going left and another right. This, however, only