All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.