> > > 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. Thanks.
