> [...]
> > > > 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.
> 
> Thanks
> Barry