From: Catalin Marinas <catalin.marinas@arm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Zhenhua Huang <quic_zhenhuah@quicinc.com>,
will@kernel.org, ardb@kernel.org, ryan.roberts@arm.com,
mark.rutland@arm.com, joey.gouly@arm.com,
dave.hansen@linux.intel.com, akpm@linux-foundation.org,
chenfeiyang@loongson.cn, chenhuacai@kernel.org,
linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] arm64: mm: vmemmap populate to page level if not section aligned
Date: Thu, 2 Jan 2025 18:58:55 +0000 [thread overview]
Message-ID: <Z3bh74I1YhGWLU4M@arm.com> (raw)
In-Reply-To: <971b9a05-4ae0-4e6c-8e48-e9e529896ecf@arm.com>
On Fri, Dec 27, 2024 at 01:19:30PM +0530, Anshuman Khandual wrote:
> On 12/24/24 19:39, Catalin Marinas wrote:
> > On Tue, Dec 24, 2024 at 05:32:06PM +0800, Zhenhua Huang wrote:
> >> I have two ideas:
> >> 1. Completely disable this PMD mapping optimization since there is no
> >> guarantee we must align 128M memory for hotplug ..
> >
> > I'd be in favour of this, at least if CONFIG_MEMORY_HOTPLUG is enabled.
> > I think the only advantage here is that we don't allocate a full 2MB
> > block for vmemmap when only plugging in a sub-section.
>
> Agreed, that will be the right fix for the problem which can be back ported.
> We will have to prevent PMD/PUD/CONT mappings for both linear and as well as
> vmemmap for all non-boot memory sections, that can be hot-unplugged.
I haven't read your diffs below yet but why not allow PMD mappings of
the hotplugged memory (not vmemmap)? SUBSECTION_SHIFT is 21, so we can
have 2MB blocks in a 4KB page configuration.
--
Catalin
next prev parent reply other threads:[~2025-01-02 19:00 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-09 9:42 [PATCH v2 0/2] Fix subsection vmemmap_populate logic Zhenhua Huang
2024-12-09 9:42 ` [PATCH v2 1/2] arm64: mm: vmemmap populate to page level if not section aligned Zhenhua Huang
2024-12-20 18:30 ` Catalin Marinas
2024-12-24 9:32 ` Zhenhua Huang
2024-12-24 14:09 ` Catalin Marinas
2024-12-25 9:59 ` Zhenhua Huang
2024-12-27 7:49 ` Anshuman Khandual
2024-12-30 7:48 ` Zhenhua Huang
2024-12-31 5:52 ` Zhenhua Huang
2025-01-02 3:16 ` Anshuman Khandual
2025-01-02 9:07 ` Zhenhua Huang
2025-01-02 3:51 ` Anshuman Khandual
2025-01-02 9:13 ` Zhenhua Huang
2025-01-02 18:58 ` Catalin Marinas [this message]
2025-01-03 2:01 ` Zhenhua Huang
2024-12-09 9:42 ` [PATCH v2 2/2] arm64: mm: implement vmemmap_check_pmd for arm64 Zhenhua Huang
2024-12-20 18:35 ` Catalin Marinas
2024-12-27 2:57 ` Anshuman Khandual
2024-12-30 7:48 ` Zhenhua Huang
2024-12-31 6:59 ` Anshuman Khandual
2024-12-31 7:18 ` Zhenhua Huang
2025-01-02 18:12 ` Catalin Marinas
2025-01-03 2:43 ` Zhenhua Huang
2025-01-03 17:58 ` Catalin Marinas
2024-12-17 1:47 ` [PATCH v2 0/2] Fix subsection vmemmap_populate logic Zhenhua Huang
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=Z3bh74I1YhGWLU4M@arm.com \
--to=catalin.marinas@arm.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=ardb@kernel.org \
--cc=chenfeiyang@loongson.cn \
--cc=chenhuacai@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=joey.gouly@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mark.rutland@arm.com \
--cc=quic_zhenhuah@quicinc.com \
--cc=ryan.roberts@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.