From: Mike Rapoport <rppt@linux.ibm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Barry Song <song.bao.hua@hisilicon.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Steve Capper <steve.capper@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Wei Li <liwei213@huawei.com>,
butao@hisilicon.com, Will Deacon <will@kernel.org>,
Ard Biesheuvel <ardb@kernel.org>,
Nicolas Saenz Julienne <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: Mon, 7 Dec 2020 11:42:15 +0200 [thread overview]
Message-ID: <20201207094215.GC1112728@linux.ibm.com> (raw)
In-Reply-To: <390f5f441d99a832f4b2425b46f6d971@kernel.org>
On Mon, Dec 07, 2020 at 09:35:06AM +0000, Marc Zyngier wrote:
> On 2020-12-07 09:09, Ard Biesheuvel wrote:
> > (+ Marc)
> >
> > On Fri, 4 Dec 2020 at 12:14, Will Deacon <will@kernel.org> 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?
> > >
> > > 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.
> > >
> >
> > Does this mean we will run into problems with the GICv3 ITS LPI tables
> > again if we are forced to reduce MAX_ORDER to fit inside
> > SECTION_SIZE_BITS?
>
> Most probably. We are already massively constraint on platforms
> such as TX1, and dividing the max allocatable range by 8 isn't
> going to make it work any better...
I don't think MAX_ORDER should shrink. Even if SECTION_SIZE_BITS is
reduced it should accomodate the existing MAX_ORDER.
My two pennies.
> M.
> --
> Jazz is not dead. It just smells funny...
--
Sincerely yours,
Mike.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.ibm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Ard Biesheuvel <ardb@kernel.org>, Will Deacon <will@kernel.org>,
Wei Li <liwei213@huawei.com>,
Barry Song <song.bao.hua@hisilicon.com>,
Steve Capper <steve.capper@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
fengbaopeng2@hisilicon.com, butao@hisilicon.com,
Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] arm64: mm: decrease the section size to reduce the memory reserved for the page map
Date: Mon, 7 Dec 2020 11:42:15 +0200 [thread overview]
Message-ID: <20201207094215.GC1112728@linux.ibm.com> (raw)
In-Reply-To: <390f5f441d99a832f4b2425b46f6d971@kernel.org>
On Mon, Dec 07, 2020 at 09:35:06AM +0000, Marc Zyngier wrote:
> On 2020-12-07 09:09, Ard Biesheuvel wrote:
> > (+ Marc)
> >
> > On Fri, 4 Dec 2020 at 12:14, Will Deacon <will@kernel.org> 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?
> > >
> > > 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.
> > >
> >
> > Does this mean we will run into problems with the GICv3 ITS LPI tables
> > again if we are forced to reduce MAX_ORDER to fit inside
> > SECTION_SIZE_BITS?
>
> Most probably. We are already massively constraint on platforms
> such as TX1, and dividing the max allocatable range by 8 isn't
> going to make it work any better...
I don't think MAX_ORDER should shrink. Even if SECTION_SIZE_BITS is
reduced it should accomodate the existing MAX_ORDER.
My two pennies.
> M.
> --
> Jazz is not dead. It just smells funny...
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2020-12-07 9:43 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)
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 [this message]
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=20201207094215.GC1112728@linux.ibm.com \
--to=rppt@linux.ibm.com \
--cc=ardb@kernel.org \
--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=maz@kernel.org \
--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.