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(+)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 8bbbd37ab105..86c3f3d9da0a 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -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
--
2.14.1
On Wed, Sep 13, 2017 at 12:10:47PM +0200, Alexandru Moise wrote:
> 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?
> 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.
--
Kirill A. Shutemov
On Fri, Sep 29, 2017 at 04:55:54PM +0300, Kirill A. Shutemov wrote:
> On Wed, Sep 13, 2017 at 12:10:47PM +0200, Alexandru Moise wrote:
> > 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.
>
> 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
>
> > 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.
>
> --
> Kirill A. Shutemov
---
mm/hugetlb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 424b0ef08a60..ab28de0122af 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -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