Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1742134 > unrolled thread

Re: [PATCH] mm/madvise: enable soft offline of HugeTLB pages at PUD level

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] mm/madvise: enable soft offline of HugeTLB pages at PUD  level "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-09-29 16:00 +0200
    Re: [PATCH] mm/madvise: enable soft offline of HugeTLB pages at PUD  level Alexandru Moise <00moses.alexander00@gmail.com> - 2017-09-29 17:00 +0200

#1742134 — Re: [PATCH] mm/madvise: enable soft offline of HugeTLB pages at PUD level

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

[toc] | [next] | [standalone]

#1742180

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web