[RFC PATCH 0/3] make the hugetlb migration strategy consistent

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

As discussed in previous thread [1], there is an inconsistency when handling
hugetlb migration. When handling the migration of freed hugetlb, it prevents
fallback to other NUMA nodes in alloc_and_dissolve_hugetlb_folio(). However,
when dealing with in-use hugetlb, it allows fallback to other NUMA nodes in
alloc_hugetlb_folio_nodemask(), which can break the per-node hugetlb pool
and might result in unexpected failures when node bound workloads doesn't get
what is asssumed available.

This patch set tries to make the hugetlb migration strategy more clear
and consistent. Please find details in each patch.

[1] https://lore.kernel.org/all/6f26ce22d2fcd523418a085f2c588fe0776d46e7.1706794035.git.baolin.wang@xxxxxxxxxxxxxxxxx/

Baolin Wang (3):
  mm: record the migration reason for struct migration_target_control
  mm: hugetlb: make the hugetlb migration strategy consistent
  docs: hugetlbpage.rst: add hugetlb migration description

 Documentation/admin-guide/mm/hugetlbpage.rst |  7 +++++
 include/linux/hugetlb.h                      |  4 +--
 mm/gup.c                                     |  1 +
 mm/hugetlb.c                                 | 28 ++++++++++++++++++--
 mm/internal.h                                |  1 +
 mm/memory-failure.c                          |  1 +
 mm/memory_hotplug.c                          |  1 +
 mm/mempolicy.c                               |  3 ++-
 mm/migrate.c                                 |  3 ++-
 mm/page_alloc.c                              |  1 +
 mm/vmscan.c                                  |  3 ++-
 11 files changed, 46 insertions(+), 7 deletions(-)

-- 
2.39.3





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux