From: Mike Rapoport <rppt@linux.ibm.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: song.bao.hua@hisilicon.com, sujunfei2@hisilicon.com,
linux-arm-kernel@lists.infradead.org, steve.capper@arm.com,
puck.chen@hisilicon.com, saberlily.xia@hisilicon.com,
linux-kernel@vger.kernel.org, fengbaopeng2@hisilicon.com,
Wei Li <liwei213@huawei.com>,
will@kernel.org, nsaenzjulienne@suse.de, butao@hisilicon.com
Subject: Re: [PATCH v2] arm64: mm: free unused memmap for sparse memory model that define VMEMMAP
Date: Thu, 3 Sep 2020 15:27:22 +0300 [thread overview]
Message-ID: <20200903122722.GI424181@linux.ibm.com> (raw)
In-Reply-To: <20200903120558.GB31409@gaia>
On Thu, Sep 03, 2020 at 01:05:58PM +0100, Catalin Marinas wrote:
> On Mon, Aug 17, 2020 at 11:04:05AM +0300, Mike Rapoport wrote:
> > On Wed, Aug 12, 2020 at 09:06:55AM +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, this patch do it.
> >
> > I've been thinking about it a bit more and it seems that instead of
> > freeing unused memory map it would be better to allocate the exact
> > memory map from the beginning.
> >
> > In sparse_init_nid() we can replace PAGES_PER_SECTION parameter to
> > __populate_section_memmap() with the calculated value for architectures
> > that define HAVE_ARCH_PFN_VALID.
>
> Or just use a smaller PAGES_PER_SECTION and reduce the waste ;).
>
> Just to be clear, are you suggesting that we should use pfn_valid() on
> the pages within a section to calculate the actual range? The
> pfn_valid() implementation on arm64 checks for the validity of a sparse
> section, so this would be called from within the sparse_init() code
> path. I hope there's no dependency but I haven't checked. If it works,
> it's fine by me, it solves the FLATMEM mem_map freeing as well.
What I meant was that sparse_init()->__populate_section_memmap() would
not blindly presume that the entire section is valid, but would take
into account The actual DRAM banks listed in memblock.memory.
For that to work we'll need a version of pfn_valid() that does not rely
on the validity of sparse section, but uses some other means, e.g.
memblock. Apparently, I've looked at arm32 version of pfn_valid() and
missed the section validity check :)
I was thinking about doing something like this for 32-bit systems
(non-ARM) that cannot affort small sections because of the limited space
in the page->flags.
> With 4KB pages on arm64, vmemmap_populate() stops at the pmd level, so
> it always allocates PMD_SIZE. Wei's patch also only frees in PMD_SIZE
> amounts. So, with a sizeof(struct page) of 64 (2^6), a PMD_SIZE mem_map
> section would cover 2^(21-6) pages, so that's equivalent to a
> SECTION_SIZE_BITS of 21-6+12 = 27.
>
> If we reduce SECTION_SIZE_BITS to 27 or less, this patch is a no-op.
>
> --
> Catalin
--
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: Catalin Marinas <catalin.marinas@arm.com>
Cc: Wei Li <liwei213@huawei.com>,
will@kernel.org, saberlily.xia@hisilicon.com,
puck.chen@hisilicon.com, butao@hisilicon.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, sujunfei2@hisilicon.com
Subject: Re: [PATCH v2] arm64: mm: free unused memmap for sparse memory model that define VMEMMAP
Date: Thu, 3 Sep 2020 15:27:22 +0300 [thread overview]
Message-ID: <20200903122722.GI424181@linux.ibm.com> (raw)
In-Reply-To: <20200903120558.GB31409@gaia>
On Thu, Sep 03, 2020 at 01:05:58PM +0100, Catalin Marinas wrote:
> On Mon, Aug 17, 2020 at 11:04:05AM +0300, Mike Rapoport wrote:
> > On Wed, Aug 12, 2020 at 09:06:55AM +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, this patch do it.
> >
> > I've been thinking about it a bit more and it seems that instead of
> > freeing unused memory map it would be better to allocate the exact
> > memory map from the beginning.
> >
> > In sparse_init_nid() we can replace PAGES_PER_SECTION parameter to
> > __populate_section_memmap() with the calculated value for architectures
> > that define HAVE_ARCH_PFN_VALID.
>
> Or just use a smaller PAGES_PER_SECTION and reduce the waste ;).
>
> Just to be clear, are you suggesting that we should use pfn_valid() on
> the pages within a section to calculate the actual range? The
> pfn_valid() implementation on arm64 checks for the validity of a sparse
> section, so this would be called from within the sparse_init() code
> path. I hope there's no dependency but I haven't checked. If it works,
> it's fine by me, it solves the FLATMEM mem_map freeing as well.
What I meant was that sparse_init()->__populate_section_memmap() would
not blindly presume that the entire section is valid, but would take
into account The actual DRAM banks listed in memblock.memory.
For that to work we'll need a version of pfn_valid() that does not rely
on the validity of sparse section, but uses some other means, e.g.
memblock. Apparently, I've looked at arm32 version of pfn_valid() and
missed the section validity check :)
I was thinking about doing something like this for 32-bit systems
(non-ARM) that cannot affort small sections because of the limited space
in the page->flags.
> With 4KB pages on arm64, vmemmap_populate() stops at the pmd level, so
> it always allocates PMD_SIZE. Wei's patch also only frees in PMD_SIZE
> amounts. So, with a sizeof(struct page) of 64 (2^6), a PMD_SIZE mem_map
> section would cover 2^(21-6) pages, so that's equivalent to a
> SECTION_SIZE_BITS of 21-6+12 = 27.
>
> If we reduce SECTION_SIZE_BITS to 27 or less, this patch is a no-op.
>
> --
> Catalin
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2020-09-03 12:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-12 1:06 [PATCH v2] arm64: mm: free unused memmap for sparse memory model that define VMEMMAP Wei Li
2020-08-12 1:06 ` Wei Li
2020-08-17 8:04 ` Mike Rapoport
2020-08-17 8:04 ` Mike Rapoport
2020-09-03 12:05 ` Catalin Marinas
2020-09-03 12:05 ` Catalin Marinas
2020-09-03 12:27 ` Mike Rapoport [this message]
2020-09-03 12:27 ` Mike Rapoport
2020-11-16 8:33 ` Song Bao Hua (Barry Song)
2020-11-16 8:33 ` Song Bao Hua (Barry Song)
2020-11-16 8:42 ` 答复: " liwei (CM)
2020-11-16 8:42 ` liwei (CM)
2020-11-16 10:46 ` Catalin Marinas
2020-11-16 10:46 ` Catalin Marinas
2020-11-23 3:45 ` 答复: " liwei (CM)
2020-11-23 3:45 ` liwei (CM)
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=20200903122722.GI424181@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=puck.chen@hisilicon.com \
--cc=saberlily.xia@hisilicon.com \
--cc=song.bao.hua@hisilicon.com \
--cc=steve.capper@arm.com \
--cc=sujunfei2@hisilicon.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.