Skip to contentSkip to conversation

mm/madvise: enable soft offline of HugeTLB pages at PUD level

PATCH In review Alexandru Moise 2 participants 3 messages Sep 13, 2017 – Sep 29, 2017

Subsystems (2)
Memory management HugeTLB
lore
Share & tools
lore

Alexandru Moise

author
#0 lore raw

PATCH 1/1 mm/madvise: enable soft offline of HugeTLB pages at PUD level

since 94310cb we've been able to soft offline 1G hugepages at the PGD level, however x86_64 gigantic hugepages are at the PUD level so we should add an extra check to account for hstate order at PUD level.

I'm not sure if this also applies to 5 level page tables on x86_64 however. Tested with 4 level pagetable.

Signed-off-by Alexandru Moise <[email protected]>
---
 include/linux/hugetlb.h | 1 +
 1 file changed, 1 insertion(+)
include/linux/hugetlb.h +1 -0
index 8bbbd37ab105..86c3f3d9da0a 100644
@@ -480,6 +480,7 @@ static inline bool hugepage_migration_supported(struct hstate *h)
 {
 #ifdef CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION
 	if ((huge_page_shift(h) == PMD_SHIFT) ||
+		(huge_page_shift(h) == PUD_SHIFT) ||
 		(huge_page_shift(h) == PGDIR_SHIFT))
 		return true;
 	else
Signature · 1 line
2.14.1
#1 lore raw
Quoted 3 lines · Alexandru Moise

since 94310cb we've been able to soft offline 1G hugepages at the PGD level, however x86_64 gigantic hugepages are at the PUD level so we should add an extra check to account for hstate order at PUD level.

Have you tested other cases affected by the change? It allows migration of 1G pages in general, which might be problematic.

It also makes these pages allocated with GFP_HIGHUSER_MOVABLE instead of GFP_HIGHUSER. Any side effects there we should consider?

Quoted 2 lines

I'm not sure if this also applies to 5 level page tables on x86_64 however. Tested with 4 level pagetable.

There's nothing changed in this regard in 5-level paging mode. PUD is still one gig and there are no new page sizes.

Signature · 1 line
 Kirill A. Shutemov
author
#2 lore raw
Quoted 7 lines · Kirill A. Shutemov
Quoted 3 lines · Alexandru Moise

since 94310cb we've been able to soft offline 1G hugepages at the PGD level, however x86_64 gigantic hugepages are at the PUD level so we should add an extra check to account for hstate order at PUD level.

Have you tested other cases affected by the change? It allows migration of 1G pages in general, which might be problematic.

Yes true, I could have done a better job explaining this in the commit message.

Quoted 3 lines

It also makes these pages allocated with GFP_HIGHUSER_MOVABLE instead of GFP_HIGHUSER. Any side effects there we should consider?

Well, it makes hugepages_treat_as_movable sysctl pointless for one.

Perhaps the below patch would be a good idea, to make this behavior optional rather.

../Alex

Quoted 9 lines
Quoted 3 lines

I'm not sure if this also applies to 5 level page tables on x86_64 however. Tested with 4 level pagetable.

There's nothing changed in this regard in 5-level paging mode. PUD is still one gig and there are no new page sizes.

Signature · 1 line
 Kirill A. Shutemov
---
 mm/hugetlb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
mm/hugetlb.c +1 -1
index 424b0ef08a60..ab28de0122af 100644
@@ -926,7 +926,7 @@ static struct page *dequeue_huge_page_nodemask(struct hstate *h, gfp_t gfp_mask,
 /* Movability of hugepages depends on migration support. */
 static inline gfp_t htlb_alloc_mask(struct hstate *h)
 {
-       if (hugepages_treat_as_movable || hugepage_migration_supported(h))
+       if (hugepages_treat_as_movable && hugepage_migration_supported(h))
                return GFP_HIGHUSER_MOVABLE;
        else
                return GFP_HIGHUSER;

--
2.14.2