On Fri, Jun 07, 2024 at 08:59:17AM +0200, David Hildenbrand wrote: > On 06.06.24 20:29, Matthew Wilcox wrote: > > One of the things we discussed at LSFMM was unifying the hugetlb and > > THP page table walkers. I've been looking into it some more recently; > > I've found a problem and I think a solution. > > > > The reason we have a separate hugetlb_entry from pmd_entry and pud_entry > > is that it has a different locking context. It is called with the > > hugetlb_vma_lock held for read (nb: this is not the same as the vma > > lock; see walk_hugetlb_range()). Why do we need this? Because of page > > table sharing. > > > > In a completely separate discussion, I was talking with Khalid about > > mshare() support for hugetlbfs, and I suggested that we permit hugetlbfs > > pages to be mapped by a VMA which does not have the VM_HUGETLB flag set. > > If we do that, the page tables would not be permitted to be shared with > > other users of that hugetlbfs file. But we want to eliminate support > > for that anyway, so that's more of a feature than a bug. > > I am not sure why hugetlb support in mshare would require that (we don't > need partial mappings and all of that to support mshare+hugetlb). You're absolutely right. My motivation is the other way around. A large part of "hugetlbfs is special" is tied to the sharing of page tables. That's why we have the hugetlb_vma_lock. If we're already sharing page tables with mshare, I assert that it is not necessary to also share page tables with other hugetlb users. So as part of including hugetlb support in mshare, we should drop that support, and handle hugetlb-mapped-with-mshare similarly to THP. Possibly not the mapcount parts so that we preserve the HVO.
