Hi, last year Peter Xu did a presention at LSFM/MM on how to better integrate hugetlb in the mm core. There are several reasons we want to do that, but one could say that the two that matter the most are 1) code duplication and 2) making hugetlb less special. During the last year several patches that went in that direction were merged e.g: gup hugetlb unify [1], mprotect for dax PUDs [2], hugetlb into generic unmapping path [3] to name some. There was also a concern on how to integrate hugetlb into the generic pagewalk, getting rid by doing so of a lot of code and have a generic path that could handle everything. This was first worked in [4] (very basic draft). Although a second version is on the works, I would like to present some concerns I have wrt. that work. HugeTLB has its own way of dealing with things. E.g: HugeTLB interprets everything as a pte: huge_pte_uffd_wp, huge_pte_clear_uffd_wp, huge_pte_dirty, huge_pte_modify, huge_pte_wrprotect etc. One of the challenges that this raises is that if we want pmd/pud walkers to be able to make sense of hugetlb stuff, we need to implement pud/pmd (maybe some pmd we already have because of THP) variants of those. E.g: HugeTLB code uses is_swap_pte and pte_to_swp_entry. If we want PUD walkers to be able to handle hugetlb, this means that we would need some sort of is_swap_pud and pud_to_swp_entry implementations. The same happens with a handful of other functions (e.g: huge_pte_*_uffd_wp, hugetlb pte markers, etc.) This has never been a problem because hugetlb has its way of doing things and we implemented code around that logic, but this falls off the cliff as soon as we want to make it less special and more generic, because we need to start implementing all those pte_* variants for pud/pmd_* I would like to know how people feel about it, whether this is something worth pursuing, or we live with the fact that HugeTLB is special, and so it remains this way. [1] https://patchwork.kernel.org/project/linux-mm/cover/20240327152332.950956-1-peterx@xxxxxxxxxx/ [2] https://patchwork.kernel.org/project/linux-mm/cover/20240812181225.1360970-1-peterx@xxxxxxxxxx/ [3] https://patchwork.kernel.org/project/linux-mm/cover/20241007075037.267650-1-osalvador@xxxxxxx/ [4] https://patchwork.kernel.org/project/linux-mm/cover/20240704043132.28501-1-osalvador@xxxxxxx/ -- Oscar Salvador SUSE Labs
