Re: [PATCH 01/15] mm/vma: introduce VMA virtual page offset field and add helpers

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Mon, Jul 20, 2026 at 03:38:16PM +0800, xu.xin16@zte.com.cn wrote:
> > > > This patch establishes fields within the vm_area_struct type to store the
> > > > virtual page offset of VMAs.
> > > >
> > > > The virtual page offset of a VMA is equal to vma->vm_start >> PAGE_SHIFT if
> > > > they are unfaulted or were not remapped, otherwise it is equal to this
> > > > value at the point of first fault.
> > > >
> > > > Currently, anonymous folios belonging to CoW'd MAP_PRIVATE-mapped
> > > > file-backed VMAs are tracked by their file offset. By adding virtual offset
> > > > as a property of VMAs, we can now track them by their virtual page offset
> > > > instead.
> > > >
> > > > By tracking this, we provide the means by which to eliminate this
> > > > inconsistency, and more importantly lay the foundations for future work for
> > > > the scalable CoW anonymous rmap rework.
> > > >
> > > > This patch simply adds the fields and some simple helpers. Subsequent
> > > > patches will update mm code to make use of these fields correctly.
> > > >
> > > > The fields chosen are packed in the VMA such that, for 64-bit kernel
> > > > builds, no additional space is taken up.
> > >
> > > It is not necessarily true that no additional memory will be consumed, as it
> > > depends on whether the baseline kernel has CONFIG_PER_VMA_LOCK enabled.
> >
> > We are moving to this being permanently enabled.
> >
> > > Moreover, in the future evolution of mm, maintaining this benefit would
> > > require that the layout of struct vm_area_struct before __vm_virt_pgoff_lo
> > > remains unchanged, which seems impractical.
> >
> > It isn't, we are very careful with this struct.
>
> Ok, That will be nice.
>
> >
> > >
> > > My personal suggestion is: maybe we could simply add an unsigned long field,
> > > say vm_virt_pgoff, without worrying about the increased memory footprint for
> > > now. Additionally, it would be helpful to add some comments clarifying the
> > > difference between this new field and the existing vm_pgoff, to aid understanding.
> >
> > Nope that'd add 64 bytes per VMA for a typical usage which can add up to a lot.
>
> Okay, but I hope at least we could be a bit more verbose in the comments, because
> __vm_virt_pgoff_lo and __vm_virt_pgoff_hi are located somewhat far apart from each
> other, which might cause considerable confusion for others seeing these two
> variables for the first time, and clarify difference between this new field and the
> existing vm_pgoff, to aid understanding.

OK, I've added comments, these ultimately refer to the vma_start_virt_pgoff()
comment which gives further details.

>
> Thanks.

Cheers, Lorenzo