Re: RFC for new feature to move pages from one vma to another without split

[Suren Baghdasaryan]

On Thu, Jun 8, 2023 at 3:05 AM Lokesh Gidra <lokeshgidra@xxxxxxxxxx> wrote:
>
> On Tue, Jun 6, 2023 at 4:18 PM Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote:
> >
> > On Tue, Jun 6, 2023 at 1:15 PM Vlastimil Babka <vbabka@xxxxxxx> wrote:
> > >
> > > On 4/13/23 17:36, Peter Xu wrote:
> > > > On Thu, Apr 13, 2023 at 10:10:44AM +0200, David Hildenbrand wrote:
> > > >> So instead, we consider the whole address space as a virtual, anon file,
> > > >> starting at offset 0. The pgoff of a VMA is then simply the offset in that
> > > >> virtual file (easily computed from the start of the VMA), and VMA merging is
> > > >> just the same as for an ordinary file.
> > > >
> > > > Interesting point, thanks!
> > >
> > > FYI, I've advised a master thesis exploring how to update page->index during
> > > mremap() to keep things mergeable:
> > >
> > > https://dspace.cuni.cz/bitstream/handle/20.500.11956/176288/120426800.pdf
> > >
> > > I think the last RFC posting was:
> > > https://lore.kernel.org/all/20220516125405.1675-1-matenajakub@xxxxxxxxx/
> > >
> > > It was really tricky for the general case. Maybe it would be more feasible
> > > for the limited case Lokesh describes, if we could be sure the pages that
> > > are moved aren't mapped anywhere else.
>
> It's great that mremap is being improved for mereabilitly. However,
> IIUC, it would still cause unnecessary splits and merges in the
> private anonymous case. Also, mremap works with mmap_sem exclusively
> held, thereby impacting scalability of concurrent mremap calls.
>
> IMHO, Andrea's userfaultfd REMAP patch is a better alternative as it
> doesn't have these downsides.
>
> >
> > Lokesh asked me to pick up this work and prepare patches for
> > upstreaming. I'll start working on them after I finish with per-vma
> > lock support for swap and userfaultd (targeting later this week).
> > Thanks for all the input folks!
>
> Thanks so much, Suren!

I just posted the patchset at
https://lore.kernel.org/all/20230914152620.2743033-1-surenb@xxxxxxxxxx/.
I tried to keep it as true to Andrea's original as possible but still
had to make some sizable changes, which I described in the cover
letter. Feedback would be much appreciated!