From: "Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com> To: Anshuman Khandual <anshuman.khandual@arm.com>, Mike Rapoport <rppt@linux.ibm.com>, Will Deacon <will@kernel.org> Cc: "steve.capper@arm.com" <steve.capper@arm.com>, "catalin.marinas@arm.com" <catalin.marinas@arm.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "nsaenzjulienne@suse.de" <nsaenzjulienne@suse.de>, "liwei (CM)" <liwei213@huawei.com>, butao <butao@hisilicon.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, fengbaopeng <fengbaopeng2@hisilicon.com> Subject: RE: [PATCH] arm64: mm: decrease the section size to reduce the memory reserved for the page map Date: Mon, 7 Dec 2020 07:47:19 +0000 [thread overview] Message-ID: <cd6e9bd9210a43948a61ad41c5cb9208@hisilicon.com> (raw) In-Reply-To: <ae384eff-448f-a8d5-a45a-e8a9234d26bb@arm.com> > -----Original Message----- > From: Anshuman Khandual [mailto:anshuman.khandual@arm.com] > Sent: Monday, December 7, 2020 8:31 PM > To: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>; Mike Rapoport > <rppt@linux.ibm.com>; Will Deacon <will@kernel.org> > Cc: steve.capper@arm.com; catalin.marinas@arm.com; > linux-kernel@vger.kernel.org; nsaenzjulienne@suse.de; liwei (CM) > <liwei213@huawei.com>; butao <butao@hisilicon.com>; > linux-arm-kernel@lists.infradead.org; fengbaopeng > <fengbaopeng2@hisilicon.com> > Subject: Re: [PATCH] arm64: mm: decrease the section size to reduce the memory > reserved for the page map > > > > On 12/7/20 7:10 AM, Song Bao Hua (Barry Song) wrote: > > > > > >> -----Original Message----- > >> From: Mike Rapoport [mailto:rppt@linux.ibm.com] > >> Sent: Saturday, December 5, 2020 12:44 AM > >> To: Will Deacon <will@kernel.org> > >> Cc: liwei (CM) <liwei213@huawei.com>; catalin.marinas@arm.com; fengbaopeng > >> <fengbaopeng2@hisilicon.com>; nsaenzjulienne@suse.de; > steve.capper@arm.com; > >> Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>; > >> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; butao > >> <butao@hisilicon.com> > >> Subject: Re: [PATCH] arm64: mm: decrease the section size to reduce the memory > >> reserved for the page map > >> > >> On Fri, Dec 04, 2020 at 11:13:47AM +0000, Will Deacon wrote: > >>> On Fri, Dec 04, 2020 at 09:44:43AM +0800, Wei Li wrote: > >>>> For the memory hole, sparse memory model that define SPARSEMEM_VMEMMAP > >>>> do not free the reserved memory for the page map, decrease the section > >>>> size can reduce the waste of reserved memory. > >>>> > >>>> Signed-off-by: Wei Li <liwei213@huawei.com> > >>>> Signed-off-by: Baopeng Feng <fengbaopeng2@hisilicon.com> > >>>> Signed-off-by: Xia Qing <saberlily.xia@hisilicon.com> > >>>> --- > >>>> arch/arm64/include/asm/sparsemem.h | 2 +- > >>>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>>> > >>>> diff --git a/arch/arm64/include/asm/sparsemem.h > >> b/arch/arm64/include/asm/sparsemem.h > >>>> index 1f43fcc79738..8963bd3def28 100644 > >>>> --- a/arch/arm64/include/asm/sparsemem.h > >>>> +++ b/arch/arm64/include/asm/sparsemem.h > >>>> @@ -7,7 +7,7 @@ > >>>> > >>>> #ifdef CONFIG_SPARSEMEM > >>>> #define MAX_PHYSMEM_BITS CONFIG_ARM64_PA_BITS > >>>> -#define SECTION_SIZE_BITS 30 > >>>> +#define SECTION_SIZE_BITS 27 > >>> > >>> We chose '30' to avoid running out of bits in the page flags. What changed? > >> > >> I think that for 64-bit there are still plenty of free bits. I didn't > >> check now, but when I played with SPARSEMEM on m68k there were 8 bits > >> for section out of 32. > >> > >>> With this patch, I can trigger: > >>> > >>> ./include/linux/mmzone.h:1170:2: error: Allocator MAX_ORDER exceeds > >> SECTION_SIZE > >>> #error Allocator MAX_ORDER exceeds SECTION_SIZE > >>> > >>> if I bump up NR_CPUS and NODES_SHIFT. > >> > >> I don't think it's related to NR_CPUS and NODES_SHIFT. > >> This seems rather 64K pages that cause this. > >> > >> Not that is shouldn't be addressed. > > > > Right now, only 4K PAGES will define ARM64_SWAPPER_USES_SECTION_MAPS. > > Other cases will use vmemmap_populate_basepages(). > > The original patch should be only addressing the issue in 4K pages: > > https://lore.kernel.org/lkml/20200812010655.96339-1-liwei213@huawei.com/ > > > > would we do something like the below? > > #ifdef CONFIG_ARM64_4K_PAGE > > #define SECTION_SIZE_BITS 27 > > #else > > #define SECTION_SIZE_BITS 30 > > #endif > > This is bit arbitrary. Probably 27 can be further reduced for 4K page size. > Instead, we should make SECTION_SIZE_BITS explicitly depend upon MAX_ORDER. > IOW section size should be the same as the highest order page in the buddy. > CONFIG_FORCE_MAX_ZONEORDER is always defined on arm64. A quick test shows > SECTION_SIZE_BITS would be 22 on 4K pages and 29 for 64K pages. As a fall > back SECTION_SIZE_BITS can still be 30 in case CONFIG_FORCE_MAX_ZONEORDER > is not defined. This will break the pmd mapping for vmemmap. As for each 128M(2^27), we can have 2MB pmd mapping. > > --- a/arch/arm64/include/asm/sparsemem.h > +++ b/arch/arm64/include/asm/sparsemem.h > @@ -7,7 +7,7 @@ > > #ifdef CONFIG_SPARSEMEM > #define MAX_PHYSMEM_BITS CONFIG_ARM64_PA_BITS > -#define SECTION_SIZE_BITS 30 > +#define SECTION_SIZE_BITS (CONFIG_FORCE_MAX_ZONEORDER - 1 + PAGE_SHIFT) > #endif > > #endif > > A similar approach exists on ia64 platform as well. Thanks Barry
WARNING: multiple messages have this Message-ID (diff)
From: "Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com> To: Anshuman Khandual <anshuman.khandual@arm.com>, Mike Rapoport <rppt@linux.ibm.com>, Will Deacon <will@kernel.org> Cc: "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "steve.capper@arm.com" <steve.capper@arm.com>, "catalin.marinas@arm.com" <catalin.marinas@arm.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "liwei \(CM\)" <liwei213@huawei.com>, fengbaopeng <fengbaopeng2@hisilicon.com>, "nsaenzjulienne@suse.de" <nsaenzjulienne@suse.de>, butao <butao@hisilicon.com> Subject: RE: [PATCH] arm64: mm: decrease the section size to reduce the memory reserved for the page map Date: Mon, 7 Dec 2020 07:47:19 +0000 [thread overview] Message-ID: <cd6e9bd9210a43948a61ad41c5cb9208@hisilicon.com> (raw) In-Reply-To: <ae384eff-448f-a8d5-a45a-e8a9234d26bb@arm.com> > -----Original Message----- > From: Anshuman Khandual [mailto:anshuman.khandual@arm.com] > Sent: Monday, December 7, 2020 8:31 PM > To: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>; Mike Rapoport > <rppt@linux.ibm.com>; Will Deacon <will@kernel.org> > Cc: steve.capper@arm.com; catalin.marinas@arm.com; > linux-kernel@vger.kernel.org; nsaenzjulienne@suse.de; liwei (CM) > <liwei213@huawei.com>; butao <butao@hisilicon.com>; > linux-arm-kernel@lists.infradead.org; fengbaopeng > <fengbaopeng2@hisilicon.com> > Subject: Re: [PATCH] arm64: mm: decrease the section size to reduce the memory > reserved for the page map > > > > On 12/7/20 7:10 AM, Song Bao Hua (Barry Song) wrote: > > > > > >> -----Original Message----- > >> From: Mike Rapoport [mailto:rppt@linux.ibm.com] > >> Sent: Saturday, December 5, 2020 12:44 AM > >> To: Will Deacon <will@kernel.org> > >> Cc: liwei (CM) <liwei213@huawei.com>; catalin.marinas@arm.com; fengbaopeng > >> <fengbaopeng2@hisilicon.com>; nsaenzjulienne@suse.de; > steve.capper@arm.com; > >> Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>; > >> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; butao > >> <butao@hisilicon.com> > >> Subject: Re: [PATCH] arm64: mm: decrease the section size to reduce the memory > >> reserved for the page map > >> > >> On Fri, Dec 04, 2020 at 11:13:47AM +0000, Will Deacon wrote: > >>> On Fri, Dec 04, 2020 at 09:44:43AM +0800, Wei Li wrote: > >>>> For the memory hole, sparse memory model that define SPARSEMEM_VMEMMAP > >>>> do not free the reserved memory for the page map, decrease the section > >>>> size can reduce the waste of reserved memory. > >>>> > >>>> Signed-off-by: Wei Li <liwei213@huawei.com> > >>>> Signed-off-by: Baopeng Feng <fengbaopeng2@hisilicon.com> > >>>> Signed-off-by: Xia Qing <saberlily.xia@hisilicon.com> > >>>> --- > >>>> arch/arm64/include/asm/sparsemem.h | 2 +- > >>>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>>> > >>>> diff --git a/arch/arm64/include/asm/sparsemem.h > >> b/arch/arm64/include/asm/sparsemem.h > >>>> index 1f43fcc79738..8963bd3def28 100644 > >>>> --- a/arch/arm64/include/asm/sparsemem.h > >>>> +++ b/arch/arm64/include/asm/sparsemem.h > >>>> @@ -7,7 +7,7 @@ > >>>> > >>>> #ifdef CONFIG_SPARSEMEM > >>>> #define MAX_PHYSMEM_BITS CONFIG_ARM64_PA_BITS > >>>> -#define SECTION_SIZE_BITS 30 > >>>> +#define SECTION_SIZE_BITS 27 > >>> > >>> We chose '30' to avoid running out of bits in the page flags. What changed? > >> > >> I think that for 64-bit there are still plenty of free bits. I didn't > >> check now, but when I played with SPARSEMEM on m68k there were 8 bits > >> for section out of 32. > >> > >>> With this patch, I can trigger: > >>> > >>> ./include/linux/mmzone.h:1170:2: error: Allocator MAX_ORDER exceeds > >> SECTION_SIZE > >>> #error Allocator MAX_ORDER exceeds SECTION_SIZE > >>> > >>> if I bump up NR_CPUS and NODES_SHIFT. > >> > >> I don't think it's related to NR_CPUS and NODES_SHIFT. > >> This seems rather 64K pages that cause this. > >> > >> Not that is shouldn't be addressed. > > > > Right now, only 4K PAGES will define ARM64_SWAPPER_USES_SECTION_MAPS. > > Other cases will use vmemmap_populate_basepages(). > > The original patch should be only addressing the issue in 4K pages: > > https://lore.kernel.org/lkml/20200812010655.96339-1-liwei213@huawei.com/ > > > > would we do something like the below? > > #ifdef CONFIG_ARM64_4K_PAGE > > #define SECTION_SIZE_BITS 27 > > #else > > #define SECTION_SIZE_BITS 30 > > #endif > > This is bit arbitrary. Probably 27 can be further reduced for 4K page size. > Instead, we should make SECTION_SIZE_BITS explicitly depend upon MAX_ORDER. > IOW section size should be the same as the highest order page in the buddy. > CONFIG_FORCE_MAX_ZONEORDER is always defined on arm64. A quick test shows > SECTION_SIZE_BITS would be 22 on 4K pages and 29 for 64K pages. As a fall > back SECTION_SIZE_BITS can still be 30 in case CONFIG_FORCE_MAX_ZONEORDER > is not defined. This will break the pmd mapping for vmemmap. As for each 128M(2^27), we can have 2MB pmd mapping. > > --- a/arch/arm64/include/asm/sparsemem.h > +++ b/arch/arm64/include/asm/sparsemem.h > @@ -7,7 +7,7 @@ > > #ifdef CONFIG_SPARSEMEM > #define MAX_PHYSMEM_BITS CONFIG_ARM64_PA_BITS > -#define SECTION_SIZE_BITS 30 > +#define SECTION_SIZE_BITS (CONFIG_FORCE_MAX_ZONEORDER - 1 + PAGE_SHIFT) > #endif > > #endif > > A similar approach exists on ia64 platform as well. Thanks Barry _______________________________________________ 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:[~2020-12-07 7:48 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-04 1:44 [PATCH] arm64: mm: decrease the section size to reduce the memory reserved for the page map Wei Li 2020-12-04 1:44 ` Wei Li 2020-12-04 1:50 ` Song Bao Hua (Barry Song) 2020-12-04 1:50 ` Song Bao Hua (Barry Song) 2020-12-04 11:13 ` Will Deacon 2020-12-04 11:13 ` Will Deacon 2020-12-04 11:44 ` Mike Rapoport 2020-12-04 11:44 ` Mike Rapoport 2020-12-07 1:40 ` Song Bao Hua (Barry Song) 2020-12-07 1:40 ` Song Bao Hua (Barry Song) 2020-12-07 7:30 ` Anshuman Khandual 2020-12-07 7:30 ` Anshuman Khandual 2020-12-07 7:47 ` Song Bao Hua (Barry Song) [this message] 2020-12-07 7:47 ` Song Bao Hua (Barry Song) 2020-12-07 9:09 ` Ard Biesheuvel 2020-12-07 9:09 ` Ard Biesheuvel 2020-12-07 9:35 ` Marc Zyngier 2020-12-07 9:35 ` Marc Zyngier 2020-12-07 9:42 ` Mike Rapoport 2020-12-07 9:42 ` Mike Rapoport 2020-12-07 9:49 ` Ard Biesheuvel 2020-12-07 9:49 ` Ard Biesheuvel 2020-12-07 10:04 ` Mike Rapoport 2020-12-07 10:04 ` Mike Rapoport 2020-12-07 10:39 ` Anshuman Khandual 2020-12-07 10:39 ` Anshuman Khandual 2020-12-07 12:07 ` Wei Li 2020-12-07 12:07 ` Wei Li
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=cd6e9bd9210a43948a61ad41c5cb9208@hisilicon.com \ --to=song.bao.hua@hisilicon.com \ --cc=anshuman.khandual@arm.com \ --cc=butao@hisilicon.com \ --cc=catalin.marinas@arm.com \ --cc=fengbaopeng2@hisilicon.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=liwei213@huawei.com \ --cc=nsaenzjulienne@suse.de \ --cc=rppt@linux.ibm.com \ --cc=steve.capper@arm.com \ --cc=will@kernel.org \ /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.