On Mon, Jul 20, 2026 at 03:38:16PM +0800, [email protected] 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
