[v1,0/5] mm/rmap: separate hugetlb rmap handling

Message

David Hildenbrand Nov. 28, 2023, 2:52 p.m. UTC

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/[e-mail]

Cc: Andrew Morton <[e-mail]>
Cc: Mike Kravetz <[e-mail]>
Cc: Muchun Song <[e-mail]>

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