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
