Re: [PATCH v9 08/69] mm: start tracking VMAs with maple tree

Liam Howlett
2022-05-10T16:58:35Z

* Liam R. Howlett <Liam.Howlett@Oracle.com> [220510 08:50]:
> * SeongJae Park <sj@kernel.org> [220510 03:37]:
> > Hi Liam,
> >
> > On Wed, 4 May 2022 01:07:52 +0000 Liam Howlett <liam.howlett@oracle.com> wrote:
> >
> > > From: "Liam R. Howlett" <Liam.Howlett@Oracle.com>
> > >
> > > Start tracking the VMAs with the new maple tree structure in parallel with
> > > the rb_tree. Add debug and trace events for maple tree operations and
> > > duplicate the rb_tree that is created on forks into the maple tree.
> > >
> > > The maple tree is added to the mm_struct including the mm_init struct,
> > > added support in required mm/mmap functions, added tracking in kernel/fork
> > > for process forking, and used to find the unmapped_area and checked
> > > against what the rbtree finds.
> > >
> > > This also moves the mmap_lock() in exit_mmap() since the oom reaper call
> > > does walk the VMAs. Otherwise lockdep will be unhappy if oom happens.
> > >
> > > Signed-off-by: Liam R. Howlett <Liam.Howlett@Oracle.com>
> > > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> > > ---
> > > arch/x86/kernel/tboot.c | 1 +
> > > drivers/firmware/efi/efi.c | 1 +
> > > include/linux/mm.h | 2 +
> > > include/linux/mm_types.h | 3 +
> > > include/trace/events/mmap.h | 73 ++++++++
> > > kernel/fork.c | 20 ++-
> > > mm/init-mm.c | 2 +
> > > mm/mmap.c | 323 +++++++++++++++++++++++++++++++++---
> > > 8 files changed, 396 insertions(+), 29 deletions(-)
> > >
> > [...]
> > > diff --git a/mm/mmap.c b/mm/mmap.c
> > > index d7e120ad5825..e777da0132f6 100644
> > > --- a/mm/mmap.c
> > > +++ b/mm/mmap.c
> > [...]
> > > @@ -680,6 +744,56 @@ static void __vma_link_file(struct vm_area_struct *vma)
> > > }
> > > }
> > >
> > > +/*
> > > + * vma_mas_store() - Store a VMA in the maple tree.
> > > + * @vma: The vm_area_struct
> > > + * @mas: The maple state
> > > + *
> > > + * Efficient way to store a VMA in the maple tree when the @mas has already
> > > + * walked to the correct location.
> > > + *
> > > + * Note: the end address is inclusive in the maple tree.
> > > + */
> > > +inline void vma_mas_store(struct vm_area_struct *vma, struct ma_state *mas)
> > > +{
> > > + trace_vma_store(mas->tree, vma);
> > > + mas_set_range(mas, vma->vm_start, vma->vm_end - 1);
> > > + mas_store_prealloc(mas, vma);
> > > +}
> > > +
> > > +/*
> > > + * vma_mas_remove() - Remove a VMA from the maple tree.
> > > + * @vma: The vm_area_struct
> > > + * @mas: The maple state
> > > + *
> > > + * Efficient way to remove a VMA from the maple tree when the @mas has already
> > > + * been established and points to the correct location.
> > > + * Note: the end address is inclusive in the maple tree.
> > > + */
> > > +static inline void vma_mas_remove(struct vm_area_struct *vma, struct ma_state *mas)
> > > +{
> > > + trace_vma_mas_szero(mas->tree, vma->vm_start, vma->vm_end - 1);
> > > + mas->index = vma->vm_start;
> > > + mas->last = vma->vm_end - 1;
> > > + mas_store_prealloc(mas, NULL);
> > > +}
> >
> > Above two functions were defined in internal.h in v8[1], but moved to mmap.c in
> > this version. As mmap.c is compiled when CONFIG_MMU, build fails when the
> > config is not set as below:
> >
> > .../mm/nommu.c: In function 'add_vma_to_mm':
> > .../mm/nommu.c:575:2: error: implicit declaration of function 'vma_mas_store'; did you mean 'mas_store'? [-Werror=implicit-function-declaration]
> > 575 | vma_mas_store(vma, &mas);
> > | ^~~~~~~~~~~~~
> > | mas_store
> > .../mm/nommu.c: In function 'delete_vma_from_mm':
> > .../mm/nommu.c:599:2: error: implicit declaration of function 'vma_mas_remove' [-Werror=implicit-function-declaration]
> > 599 | vma_mas_remove(vma, &mas);
> > | ^~~~~~~~~~~~~~
> >
> > Was there a reason to move these definitions? I confirmed moving the
> > definition back to internal.h fixes this issue, but I'm unsure if that's the
> > right solution.
> >
> > [1] https://lore.kernel.org/linux-mm/20220426150616.3937571-10-Liam.Howlett@oracle.com/
> >
>
> I moved the functions as they were dropped elsewhere for cleanup. I did
> check my m68k buildroot, but the buildroot seems to have not pulled the
> new code - it clones the repo externally. I just changed the branch to
> use mm-unstable and that is indeed failing as you see above. Your fix
> is correct - and I believe it also means I need to leave the damon
> change the way it is now.
>

I recall now that I wanted to have the function traced. Moving it to
the c file allowed me to add tracepoints pretty easily. Having it in
the header does not work as it will redefine the tracepoints many times
and cause a bit of a mess. I don't love putting the tracepoint as is in
another function but I think I will have to move to this method. On the
plus side, the open-coded modifications to the maple tree may be able to
use the tracepoints then.