Let's just cleanly separate hugetlb rmap handling from "ordinary" rmap handling, like we already do when adding anon hugetlb folios. We have hugetlb special-casing/checks in the callers in all cases either way already in place: it doesn't make too much sense to call generic-looking functions that end up doing hugetlb specific things from hugetlb special-cases. This now also means that we won't run into "folio_test_pmd_mappable()" cases for hugetlb, which doesn't make too much sense with gigantic hugetlb folios that are in fact currently only PUD-mappable. Or having a folio_add_file_rmap() function that looks like it clould be used by hugetlb code, but really can't. This is a stanalone cleanup, but it gets more relevant when adding more rmap batching (we cannot map parts of a hugetlb folio) or changing the way we handle partially-mappable folios as in [1], whereby we'd have to add more hugetlb special casing to keep hugetlb working as is. If ever something about hugetlb changes that makes them actually partially-mappable folios, we can look into cleanly merging all code paths, not just some. [1] https://lkml.kernel.org/r/20231124132626.235350-1-david@xxxxxxxxxx Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> Cc: Mike Kravetz <mike.kravetz@xxxxxxxxxx> Cc: Muchun Song <muchun.song@xxxxxxxxx> David Hildenbrand (5): mm/rmap: rename hugepage_add* to hugetlb_add* mm/rmap: introduce and use hugetlb_remove_rmap() mm/rmap: introduce and use hugetlb_add_file_rmap() mm/rmap: introduce and use hugetlb_try_dup_anon_rmap() mm/rmap: add hugetlb sanity checks include/linux/mm.h | 12 +++++++++--- include/linux/rmap.h | 37 +++++++++++++++++++++++++++++++++++-- mm/hugetlb.c | 21 ++++++++++----------- mm/migrate.c | 6 +++--- mm/rmap.c | 31 ++++++++++++++++++------------- 5 files changed, 75 insertions(+), 32 deletions(-) base-commit: b85ea95d086471afb4ad062012a4d73cd328fa86 -- 2.41.0
