All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@linux.ibm.com>
To: Will Deacon <will@kernel.org>
Cc: Wei Li <liwei213@huawei.com>,
	catalin.marinas@arm.com, fengbaopeng2@hisilicon.com,
	nsaenzjulienne@suse.de, steve.capper@arm.com,
	song.bao.hua@hisilicon.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, butao@hisilicon.com
Subject: Re: [PATCH] arm64: mm: decrease the section size to reduce the memory reserved for the page map
Date: Fri, 4 Dec 2020 13:44:00 +0200	[thread overview]
Message-ID: <20201204114400.GT123287@linux.ibm.com> (raw)
In-Reply-To: <20201204111347.GA844@willie-the-truck>

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.

> Will

-- 
Sincerely yours,
Mike.

WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.ibm.com>
To: Will Deacon <will@kernel.org>
Cc: song.bao.hua@hisilicon.com, linux-arm-kernel@lists.infradead.org,
	steve.capper@arm.com, catalin.marinas@arm.com,
	linux-kernel@vger.kernel.org, Wei Li <liwei213@huawei.com>,
	butao@hisilicon.com, nsaenzjulienne@suse.de,
	fengbaopeng2@hisilicon.com
Subject: Re: [PATCH] arm64: mm: decrease the section size to reduce the memory reserved for the page map
Date: Fri, 4 Dec 2020 13:44:00 +0200	[thread overview]
Message-ID: <20201204114400.GT123287@linux.ibm.com> (raw)
In-Reply-To: <20201204111347.GA844@willie-the-truck>

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.

> Will

-- 
Sincerely yours,
Mike.

_______________________________________________
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-04 11:45 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 [this message]
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)
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=20201204114400.GT123287@linux.ibm.com \
    --to=rppt@linux.ibm.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=song.bao.hua@hisilicon.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.