From: Baoquan He <bhe@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: catalin.marinas@arm.com, will@kernel.org, horms@kernel.org,
thunder.leizhen@huawei.com, John.p.donnelly@oracle.com,
kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v6 1/2] arm64: kdump: simplify the reservation behaviour of crashkernel=,high
Date: Mon, 15 May 2023 18:07:09 +0800 [thread overview]
Message-ID: <ZGIETQZWp3scdS/m@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20230515060259.830662-2-bhe@redhat.com>
On 05/15/23 at 02:02pm, Baoquan He wrote:
> On arm64, reservation for 'crashkernel=xM,high' is taken by searching for
> suitable memory region top down. If the 'xM' of crashkernel high memory
> is reserved from high memory successfully, it will try to reserve
> crashkernel low memory later accoringly. Otherwise, it will try to search
> low memory area for the 'xM' suitable region. Please see the details in
> Documentation/admin-guide/kernel-parameters.txt.
>
> While we observed an unexpected case where a reserved region crosses the
> high and low meomry boundary. E.g on a system with 4G as low memory end,
> user added the kernel parameters like: 'crashkernel=512M,high', it could
> finally have [4G-126M, 4G+386M], [1G, 1G+128M] regions in running kernel.
> The crashkernel high region crossing low and high memory boudary will bring
> issues:
>
> 1) For crashkernel=x,high, if getting crashkernel high region across
> low and high memory boundary, then user will see two memory regions in
> low memory, and one memory region in high memory. The two crashkernel
> low memory regions are confusing as shown in above example.
>
> 2) If people explicityly specify "crashkernel=x,high crashkernel=y,low"
> and y <= 128M, when crashkernel high region crosses low and high memory
> boundary and the part of crashkernel high reservation below boundary is
> bigger than y, the expected crahskernel low reservation will be skipped.
> But the expected crashkernel high reservation is shrank and could not
> satisfy user space requirement.
>
> 3) The crossing boundary behaviour of crahskernel high reservation is
> different than x86 arch. On x86_64, the low memory end is 4G fixedly,
> and the memory near 4G is reserved by system, e.g for mapping firmware,
> pci mapping, so the crashkernel reservation crossing boundary never happens.
> From distros point of view, this brings inconsistency and confusion. Users
> need to dig into x86 and arm64 system details to find out why.
>
> For kernel itself, the impact of issue 3) could be slight. While issue
> 1) and 2) cause actual impact because it brings obscure semantics and
> behaviour to crashkernel=,high reservation.
>
> Here, for crashkernel=xM,high, search the high memory for the suitable
> region only in high memory. If failed, try reserving the suitable
> region only in low memory. Like this, the crashkernel high region will
> only exist in high memory, and crashkernel low region only exists in low
> memory. The reservation behaviour for crashkernel=,high is clearer and
> simpler.
>
> Note: RPi4 has different zone ranges than normal memory. Its DMA zone is
> 0~1G, and DMA32 zone is 1G~4G if CONFIG_ZONE_DMA|DMA32 are enabled by
> default. The low memory end is 1G in order to validate all devices, high
> memory starts at 1G memory. However, for being consistent with normla
> arm64 system, its low memory end is still 1G, while reserving crashkernel
> high memory from 4G if crashkernel=size,high specified. This will remove
> confusion.
>
> With above change applied, summary of arm64 crashkernel reservation range:
> 1)
> RPi4(zone DMA:0~1G; DMA32:1G~4G):
> crashkernel=size
> 0~1G: low memory | 1G~top: high memory
>
> crashkernel=size,high
> 0~1G: low memory | 4G~top: high memory
>
> 2)
> Other normal system:
> crashkernel=size
> crashkernel=size,high
> 0~4G: low memory | 4G~top: high memory
>
> 3)
> Systems w/o zone DMA|DMA32
> crashkernel=size
> crashkernel=size,high
> 0~top: low memory
>
> Signed-off-by: Baoquan He <bhe@redhat.com>
>
> arm64: kdump: fix warning reported by static checker
> Signed-off-by: Baoquan He <bhe@redhat.com>
Sorry, forgot cleaning up this relic of local patch merging, have resent
one to remove it, and add Catalin's Reviewed-by tag.
Thanks
Baoquan
next prev parent reply other threads:[~2023-05-15 10:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-15 6:02 [PATCH v6 0/2] arm64: kdump: simplify the reservation behaviour of crashkernel=,high Baoquan He
2023-05-15 6:02 ` [PATCH v6 1/2] " Baoquan He
2023-05-15 9:54 ` [PATCH v6 RESEND " Baoquan He
2023-06-06 11:53 ` Leizhen (ThunderTown)
2023-05-15 10:07 ` Baoquan He [this message]
2023-05-15 6:02 ` [PATCH v6 2/2] Documentation: add kdump.rst to present crashkernel reservation on arm64 Baoquan He
2023-06-06 12:08 ` Leizhen (ThunderTown)
2023-06-09 19:30 ` [PATCH v6 0/2] arm64: kdump: simplify the reservation behaviour of crashkernel=,high Catalin Marinas
2023-06-11 0:35 ` Baoquan He
2023-06-11 12:15 ` Baoquan He
2023-06-11 14:31 ` Catalin Marinas
2023-06-11 23:06 ` Baoquan He
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=ZGIETQZWp3scdS/m@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=John.p.donnelly@oracle.com \
--cc=catalin.marinas@arm.com \
--cc=horms@kernel.org \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=thunder.leizhen@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).