Re: [PATCH 0/15] mm: introduce ANON_VMA_LAZY for deferred anon_vma creation

[Suren Baghdasaryan]

On Thu, Jun 4, 2026 at 12:35 AM wangtao <tao.wangtao@xxxxxxxxx> wrote:
>
> > [...]
> > > > > I won't echo what has already been said in this thread (and I
> > > > > didn't manage to read all, unfortunately), but for such big and
> > > > > invasive work it's often best to get in touch with the community
> > > > > earlier. Otherwise, you might end up wasting your time.
> > > > >
> > > > > Ok, arguably, someone who writes that code learns a lot on the way.
> > > > > And if this code really was written by one developer only, I tip
> > > > > my hat! I'd be curious if that code already ran somewhere on some
> > > > > Android
> > > > kernel out there?
> > > >
> > > > I heard from Zicheng that they have been running this for months and
> > > > it seems reasonably stable. Please correct me if I'm wrong, Zicheng
> > > > :-). This really should have been discussed with the community earlier.
> > > >
> > > I initially developed and debugged this based on the Android GKI
> > > branch and did some preliminary testing on an Android phone.
> > >
> > > Since GKI generally only accepts features merged from the upstream
> > > community, and this memory saving could also benefit the community, I
> > > ported the patch to the Linux master branch.
> > >
> > > Because my English is not very good and I rarely participate in the
> > > community, I am not familiar with the community workflow. I did not
> > > send an email for discussion in advance with an RFC tag. I apologize again.
> > >
> >
> > No worries. I know someone who has worked on the Linux kernel for many,
> > many years and has excellent kernel expertise, yet has never submitted a
> > patch throughout his career for various reasons.
> >
> > I heard from Zicheng that you are HONOR's key MM expert and have been
> > guiding them on memory-management related work. That's really impressive.
> > Personally, I'd love to see more ideas and contributions from you in the linux-
> > mm community.
> >
> > BTW, regarding my earlier suggestion about using GKI hooks—limiting the
> > optimization to newly created VMAs and to applications that never call
> > fork()—do you have any ideas on what the smallest possible hook change
> > would look like?
> Even if Android does not consider handling for 32-bit, KSM, or
> memory-failure, a large number of hooks are still required.
>
> A different implementation approach is also needed. For example, one
> or a set of anon_vma_locks could be used to mark whether a VMA is
> lazy, so that we can avoid modifying all places that dereference
> anon_vma. Reserved fields in vma could be used to record the root_vma
> and a reference count respectively.
>
> Roughly, hooks would be needed in the following places:
>
> 1. __vmf_anon_prepare: mark lazy_vma in the fault path.
> 2. __folio_set_anon and folio_move_anon_rmap: set mapping to lazy_vma.
> 3. rmap_walk_anon: handle rmap_walk for lazy_vma.
> 4. folio_get_anon_vma and put_anon_vma: add hooks to distinguish
>    lazy_vma handling.
> 5. anon_vma_fork: decide whether to upgrade pvma->anon_vma.
> 6. Add a hook in try_dup_anon_rmap to upgrade folio->mapping.
> 7. anon_vma_clone: handle links when src is a lazy_vma.
> 8. vm_area_alloc / vm_area_dup / vm_area_free: add VMA reference
>    counting.
> 9. mremap: handle upgrades in copy_vma and move_page_tables.
>
> If this can be restricted to apps only and the app never calls fork(),
> then 5 and 6 could also be removed.
>
> If each page's mapping in the page tables is synchronously updated
> when upgrading lazy_vma, then 4 and 5 could be merged into one.
>
> If lazy_vma is restricted to anonymous VMAs where
> vma_mapping_base(vma) = 0, then root_vma and the VMA reference count
> could also be removed.
>
> With this restriction, we could directly use folio->mapping to record
> mm, and locate the vma using folio->index, which would simplify this
> patch series.

After looking over the patchset I must agree with other reviewers that
it makes the already complicated rmap code much more complex. Adding
this into GKI as an out-of-tree patchset is an absolute non-starter. I
don't think you can refactor this logic to be contained in a vendor
module and without affecting the ABI, but even if you manage that
somehow, it would be a maintenance nightmare. I would rather spend
time backporting upstream-accepted solution than try to debug
unexpected custom behavior down the road. I believe Lorenzo's solution
will have similar memory savings and I suggest we all help it succeed.

On a separate note, it's very encouraging to see more Android partners
becoming active upstream. For years partners developed optimizations
in isolation without engaging with the community or sharing their
ideas. This is a very positive development which I believe will
benefit both the community and the engaging partners. From my own
experience, learning to collaborate upstream takes time, but once it's
done the experience is very rewarding and oftentimes even the biggest
critics turn into supporters. The key is to listen to the feedback,
ignore harsh words and realize that people here ultimately have the
same goals. So, don't be discouraged by this experience. I think the
biggest mistake here was the lack of prior discussions or RFCs for
such a big and invasive change.
Thanks,
Suren.

> >
> > Thanks
> > Barry