From: Muchun Song <songmuchun@bytedance.com> To: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Will Deacon <will@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, David Hildenbrand <david@redhat.com>, "Bodeddula, Balasubramaniam" <bodeddub@amazon.com>, Oscar Salvador <osalvador@suse.de>, Mike Kravetz <mike.kravetz@oracle.com>, David Rientjes <rientjes@google.com>, linux-arm-kernel@lists.infradead.org, LKML <linux-kernel@vger.kernel.org>, Linux Memory Management List <linux-mm@kvack.org>, Xiongchun duan <duanxiongchun@bytedance.com>, fam.zheng@bytedance.com, zhengqi.arch@bytedance.com Subject: Re: [External] Re: [PATCH] arm64: mm: hugetlb: add support for free vmemmap pages of HugeTLB Date: Wed, 19 May 2021 23:22:44 +0800 [thread overview] Message-ID: <CAMZfGtWpu=pDqn2WZ4QPTevvHmjMaXg8oN8rh1KCDXwievzNrw@mail.gmail.com> (raw) In-Reply-To: <CAMZfGtVJrnQ6Nb25CON3WupOx-K3BFzQ2t546r0xsT45vZD+4w@mail.gmail.com> On Wed, May 19, 2021 at 10:43 PM Muchun Song <songmuchun@bytedance.com> wrote: > > On Wed, May 19, 2021 at 8:35 PM Anshuman Khandual > <anshuman.khandual@arm.com> wrote: > > > > > > On 5/18/21 2:48 PM, Muchun Song wrote: > > > The preparation of supporting freeing vmemmap associated with each > > > HugeTLB page is ready, so we can support this feature for arm64. > > > > > > Signed-off-by: Muchun Song <songmuchun@bytedance.com> > > > --- > > > arch/arm64/mm/mmu.c | 5 +++++ > > > fs/Kconfig | 2 +- > > > 2 files changed, 6 insertions(+), 1 deletion(-) > > > > > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c > > > index 5d37e461c41f..967b01ce468d 100644 > > > --- a/arch/arm64/mm/mmu.c > > > +++ b/arch/arm64/mm/mmu.c > > > @@ -23,6 +23,7 @@ > > > #include <linux/mm.h> > > > #include <linux/vmalloc.h> > > > #include <linux/set_memory.h> > > > +#include <linux/hugetlb.h> > > > > > > #include <asm/barrier.h> > > > #include <asm/cputype.h> > > > @@ -1134,6 +1135,10 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, > > > pmd_t *pmdp; > > > > > > WARN_ON((start < VMEMMAP_START) || (end > VMEMMAP_END)); > > > + > > > + if (is_hugetlb_free_vmemmap_enabled() && !altmap) > > > + return vmemmap_populate_basepages(start, end, node, altmap); > > > + > > > do { > > > next = pmd_addr_end(addr, end); > > > > > > diff --git a/fs/Kconfig b/fs/Kconfig > > > index 6ce6fdac00a3..02c2d3bf1cb8 100644 > > > --- a/fs/Kconfig > > > +++ b/fs/Kconfig > > > @@ -242,7 +242,7 @@ config HUGETLB_PAGE > > > > > > config HUGETLB_PAGE_FREE_VMEMMAP > > > def_bool HUGETLB_PAGE > > > - depends on X86_64 > > > + depends on X86_64 || ARM64 > > > depends on SPARSEMEM_VMEMMAP > > > > > > config MEMFD_CREATE > > > > > > > How does this interact with HugeTLB migration as such which might iterate > > over individual constituent struct pages (overriding the same struct page > > for all tail pages when this feature is enabled). A simple test involving > > madvise(ptr, size, MADV_SOFT_OFFLINE) fails on various HugeTLB page sizes, > > with this patch applied. Although I have not debugged this any further. > > It is weird. Actually, I didn't change the behaviour of the page migration. > This feature is default off. If you want to enable this feature, you can pass > "hugetlb_free_vmemmap=on" to the boot cmdline. Do you mean that the > success rate of page migration will decrease when you enable this feature? > The rate will increase if disbale. Right? I have done the test and found the issue. Because unmap_and_move_huge_page always returns -EBUSY. I will look into this issue in depth. Thanks for your report. The return point is as below: if (page_private(hpage) && !page_mapping(hpage)) { rc = -EBUSY; goto out_unlock; } > > Thanks. > > > > > > Soft offlining pfn 0x101c00 at process virtual address 0xffff7fa00000 > > soft offline: 0x101c00: hugepage migration failed 1, type bfffc0000010006 > > (referenced|uptodate|head|node=0|zone=2|lastcpupid=0xffff) > >
WARNING: multiple messages have this Message-ID (diff)
From: Muchun Song <songmuchun@bytedance.com> To: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Will Deacon <will@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, David Hildenbrand <david@redhat.com>, "Bodeddula, Balasubramaniam" <bodeddub@amazon.com>, Oscar Salvador <osalvador@suse.de>, Mike Kravetz <mike.kravetz@oracle.com>, David Rientjes <rientjes@google.com>, linux-arm-kernel@lists.infradead.org, LKML <linux-kernel@vger.kernel.org>, Linux Memory Management List <linux-mm@kvack.org>, Xiongchun duan <duanxiongchun@bytedance.com>, fam.zheng@bytedance.com, zhengqi.arch@bytedance.com Subject: Re: [External] Re: [PATCH] arm64: mm: hugetlb: add support for free vmemmap pages of HugeTLB Date: Wed, 19 May 2021 23:22:44 +0800 [thread overview] Message-ID: <CAMZfGtWpu=pDqn2WZ4QPTevvHmjMaXg8oN8rh1KCDXwievzNrw@mail.gmail.com> (raw) In-Reply-To: <CAMZfGtVJrnQ6Nb25CON3WupOx-K3BFzQ2t546r0xsT45vZD+4w@mail.gmail.com> On Wed, May 19, 2021 at 10:43 PM Muchun Song <songmuchun@bytedance.com> wrote: > > On Wed, May 19, 2021 at 8:35 PM Anshuman Khandual > <anshuman.khandual@arm.com> wrote: > > > > > > On 5/18/21 2:48 PM, Muchun Song wrote: > > > The preparation of supporting freeing vmemmap associated with each > > > HugeTLB page is ready, so we can support this feature for arm64. > > > > > > Signed-off-by: Muchun Song <songmuchun@bytedance.com> > > > --- > > > arch/arm64/mm/mmu.c | 5 +++++ > > > fs/Kconfig | 2 +- > > > 2 files changed, 6 insertions(+), 1 deletion(-) > > > > > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c > > > index 5d37e461c41f..967b01ce468d 100644 > > > --- a/arch/arm64/mm/mmu.c > > > +++ b/arch/arm64/mm/mmu.c > > > @@ -23,6 +23,7 @@ > > > #include <linux/mm.h> > > > #include <linux/vmalloc.h> > > > #include <linux/set_memory.h> > > > +#include <linux/hugetlb.h> > > > > > > #include <asm/barrier.h> > > > #include <asm/cputype.h> > > > @@ -1134,6 +1135,10 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, > > > pmd_t *pmdp; > > > > > > WARN_ON((start < VMEMMAP_START) || (end > VMEMMAP_END)); > > > + > > > + if (is_hugetlb_free_vmemmap_enabled() && !altmap) > > > + return vmemmap_populate_basepages(start, end, node, altmap); > > > + > > > do { > > > next = pmd_addr_end(addr, end); > > > > > > diff --git a/fs/Kconfig b/fs/Kconfig > > > index 6ce6fdac00a3..02c2d3bf1cb8 100644 > > > --- a/fs/Kconfig > > > +++ b/fs/Kconfig > > > @@ -242,7 +242,7 @@ config HUGETLB_PAGE > > > > > > config HUGETLB_PAGE_FREE_VMEMMAP > > > def_bool HUGETLB_PAGE > > > - depends on X86_64 > > > + depends on X86_64 || ARM64 > > > depends on SPARSEMEM_VMEMMAP > > > > > > config MEMFD_CREATE > > > > > > > How does this interact with HugeTLB migration as such which might iterate > > over individual constituent struct pages (overriding the same struct page > > for all tail pages when this feature is enabled). A simple test involving > > madvise(ptr, size, MADV_SOFT_OFFLINE) fails on various HugeTLB page sizes, > > with this patch applied. Although I have not debugged this any further. > > It is weird. Actually, I didn't change the behaviour of the page migration. > This feature is default off. If you want to enable this feature, you can pass > "hugetlb_free_vmemmap=on" to the boot cmdline. Do you mean that the > success rate of page migration will decrease when you enable this feature? > The rate will increase if disbale. Right? I have done the test and found the issue. Because unmap_and_move_huge_page always returns -EBUSY. I will look into this issue in depth. Thanks for your report. The return point is as below: if (page_private(hpage) && !page_mapping(hpage)) { rc = -EBUSY; goto out_unlock; } > > Thanks. > > > > > > Soft offlining pfn 0x101c00 at process virtual address 0xffff7fa00000 > > soft offline: 0x101c00: hugepage migration failed 1, type bfffc0000010006 > > (referenced|uptodate|head|node=0|zone=2|lastcpupid=0xffff) > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-05-19 15:23 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-18 9:18 [PATCH] arm64: mm: hugetlb: add support for free vmemmap pages of HugeTLB Muchun Song 2021-05-18 9:18 ` Muchun Song 2021-05-19 11:45 ` Anshuman Khandual 2021-05-19 11:45 ` Anshuman Khandual 2021-05-19 12:03 ` David Hildenbrand 2021-05-19 12:03 ` David Hildenbrand 2021-05-20 11:54 ` Anshuman Khandual 2021-05-20 11:54 ` Anshuman Khandual 2021-05-20 11:59 ` David Hildenbrand 2021-05-20 11:59 ` David Hildenbrand 2021-05-21 5:02 ` Anshuman Khandual 2021-05-21 5:02 ` Anshuman Khandual 2021-05-19 12:49 ` [External] " Muchun Song 2021-05-19 12:49 ` Muchun Song 2021-05-19 12:49 ` Muchun Song 2021-05-20 12:00 ` Anshuman Khandual 2021-05-20 12:00 ` Anshuman Khandual 2021-05-19 12:36 ` Anshuman Khandual 2021-05-19 12:36 ` Anshuman Khandual 2021-05-19 14:43 ` [External] " Muchun Song 2021-05-19 14:43 ` Muchun Song 2021-05-19 14:43 ` Muchun Song 2021-05-19 15:22 ` Muchun Song [this message] 2021-05-19 15:22 ` Muchun Song 2021-05-19 15:22 ` Muchun Song 2021-05-19 16:21 ` Muchun Song 2021-05-19 16:21 ` Muchun Song 2021-05-19 16:21 ` Muchun Song 2021-05-19 22:44 ` Mike Kravetz 2021-05-19 22:44 ` Mike Kravetz
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAMZfGtWpu=pDqn2WZ4QPTevvHmjMaXg8oN8rh1KCDXwievzNrw@mail.gmail.com' \ --to=songmuchun@bytedance.com \ --cc=akpm@linux-foundation.org \ --cc=anshuman.khandual@arm.com \ --cc=bodeddub@amazon.com \ --cc=david@redhat.com \ --cc=duanxiongchun@bytedance.com \ --cc=fam.zheng@bytedance.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mike.kravetz@oracle.com \ --cc=osalvador@suse.de \ --cc=rientjes@google.com \ --cc=will@kernel.org \ --cc=zhengqi.arch@bytedance.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.