[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220419175735.5737a3z4owx3wyzx@revolver>
Date: Tue, 19 Apr 2022 17:57:46 +0000
From: Liam Howlett <liam.howlett@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: Yang Shi <shy828301@...il.com>,
"maple-tree@...ts.infradead.org" <maple-tree@...ts.infradead.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v7 26/70] mm/mmap: Use advanced maple tree API for
mmap_region()
* Andrew Morton <akpm@...ux-foundation.org> [220414 02:51]:
> On Mon, 4 Apr 2022 14:35:43 +0000 Liam Howlett <liam.howlett@...cle.com> wrote:
>
> > From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
> >
> > Changing mmap_region() to use the maple tree state and the advanced
> > maple tree interface allows for a lot less tree walking.
> >
> > This change removes the last caller of munmap_vma_range(), so drop this
> > unused function.
> >
> > Add vma_expand() to expand a VMA if possible by doing the necessary
> > hugepage check, uprobe_munmap of files, dcache flush, modifications then
> > undoing the detaches, etc.
> >
>
> Merging this with Yang Shi's "mm: mmap: register suitable readonly file
> vmas for khugepaged"
> (https://lkml.kernel.org/r/20220404200250.321455-9-shy828301@gmail.com)
>
> > ...
> >
> > @@ -1741,13 +1868,28 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
> > goto free_vma;
> > }
> >
> > - vma_link(mm, vma, prev);
> > + if (vma->vm_file)
> > + i_mmap_lock_write(vma->vm_file->f_mapping);
> > +
> > + vma_mas_store(vma, &mas);
> > + __vma_link_list(mm, vma, prev);
> > + mm->map_count++;
> > + if (vma->vm_file) {
> > + if (vma->vm_flags & VM_SHARED)
> > + mapping_allow_writable(vma->vm_file->f_mapping);
> > +
> > + flush_dcache_mmap_lock(vma->vm_file->f_mapping);
> > + vma_interval_tree_insert(vma, &vma->vm_file->f_mapping->i_mmap);
> > + flush_dcache_mmap_unlock(vma->vm_file->f_mapping);
> > + i_mmap_unlock_write(vma->vm_file->f_mapping);
> > + }
> > +
> > /* Once vma denies write, undo our temporary denial count */
> > unmap_writable:
> > if (file && vm_flags & VM_SHARED)
> > mapping_unmap_writable(file->f_mapping);
>
> I'm unsure whether this hunk should be inside or outside the call to
> the cheerfully undocumented khugepaged_enter_vma()?
Below. I've replaced the vma_link() with a write to the tree and
inlined the handling of vm_file. At least, it will keep with what Yang
Shi wrote in the patch you are merging.
>
>
> Code snippet as I presently have it:
>
> if (vma->vm_file)
> i_mmap_lock_write(vma->vm_file->f_mapping);
>
> vma_mas_store(vma, &mas);
> mm->map_count++;
> if (vma->vm_file) {
> if (vma->vm_flags & VM_SHARED)
> mapping_allow_writable(vma->vm_file->f_mapping);
>
> flush_dcache_mmap_lock(vma->vm_file->f_mapping);
> vma_interval_tree_insert(vma, &vma->vm_file->f_mapping->i_mmap);
> flush_dcache_mmap_unlock(vma->vm_file->f_mapping);
> i_mmap_unlock_write(vma->vm_file->f_mapping);
> }
>
> /*
> * vma_merge() calls khugepaged_enter_vma() either, the below
> * call covers the non-merge case.
> */
> khugepaged_enter_vma(vma, vma->vm_flags);
>
> /* Once vma denies write, undo our temporary denial count */
> unmap_writable:
> if (file && vm_flags & VM_SHARED)
> mapping_unmap_writable(file->f_mapping);
>
> btw, "vma_merge() calls khugepaged_enter_vma() either" isn't
> understandable. Should that be "also"?
It looks like it should be "also" to me.. Yang Shi?
Powered by blists - more mailing lists