From: Catalin Marinas <catalin.marinas@arm.com>
To: kexec@lists.infradead.org
Subject: [PATCH v22 5/9] arm64: kdump: Reimplement crashkernel=X
Date: Thu, 5 May 2022 15:20:18 +0100 [thread overview]
Message-ID: <YnPdIvOktZBQYLjg@arm.com> (raw)
In-Reply-To: <YnM9w69l5dbE+k15@MiWiFi-R3L-srv>
On Thu, May 05, 2022 at 11:00:19AM +0800, Baoquan He wrote:
> On 05/03/22 at 11:00pm, Catalin Marinas wrote:
> > So, to recap, IIUC you are fine with:
> >
> > crashkernel=Y - allocate within ZONE_DMA with fallback
> > above with a default in ZONE_DMA (like
> > x86, 256M or swiotlb size)
>
> Ack to this one.
>
>
> > crashkernel=Y,high - allocate from above ZONE_DMA
>
> Not exactly. If there's only ZONE_DMA, crashkernel,high will
> be reserved in ZONE_DMA, and crashkernel,low will be ignored.
> Other than this, ack.
Yes, that's fine.
> > crashkernel=Y,low - allocate within ZONE_DMA
>
> Ack to this one.
> >
> > 'crashkernel' overrides the high and low while the latter two can be
> > passed independently.
>
> crashkernel=,high can be passed independently, then a crashkernel=,low
> is needed implicitly. If people don't want crashkernel=,low
> explicitly, crashkernel=0,low need be specified.
I find this complicating the interface. I don't know the background to
the x86 implementation but we diverge already on arm64 since we talk
about ZONE_DMA rather than 4G limit (though for most platforms these
would be the same).
I guess we could restate the difference between crashkernel= and
crashkernel=,high as the hint to go for allocation above ZONE_DMA first.
> An independent crashkernel=,low makes no sense. Crashkernel=,low
> should be paird with crashkernel=,high.
You could argue that crashkernel=,low gives the current crashkernel=
behaviour, i.e. either all within ZONE_DMA or fail to allocate. So it
may have some value on its own.
> My personal opinion according to the existed senmantics on x86.
> Otherwise, the guidance of crashkernel= |,high|,low reservation
> will be complicated to write.
It's more that I find the current semantics unnecessarily confusing. But
even reading the x86_64 text it's not that clear. For example the
default low allocation for crashkernel= and crashkernel=,high is only
mentioned in the crashkernel=,low description.
--
Catalin
next prev parent reply other threads:[~2022-05-05 14:20 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-14 11:57 [PATCH v22 0/9] support reserving crashkernel above 4G on arm64 kdump Zhen Lei
2022-04-14 11:57 ` [PATCH v22 1/9] kdump: return -ENOENT if required cmdline option does not exist Zhen Lei
2022-04-25 3:49 ` Baoquan He
2022-04-14 11:57 ` [PATCH v22 2/9] arm64: Use insert_resource() to simplify code Zhen Lei
2022-04-14 11:57 ` [PATCH v22 3/9] arm64: kdump: Remove some redundant checks in map_mem() Zhen Lei
2022-04-14 11:57 ` [PATCH v22 4/9] arm64: kdump: Don't force page-level mappings for memory above 4G Zhen Lei
2022-04-26 14:26 ` Catalin Marinas
2022-04-27 7:12 ` Leizhen
2022-04-14 11:57 ` [PATCH v22 5/9] arm64: kdump: Reimplement crashkernel=X Zhen Lei
2022-04-26 18:02 ` Catalin Marinas
2022-04-27 6:54 ` Leizhen
2022-04-27 12:32 ` Catalin Marinas
2022-04-27 13:49 ` Leizhen
2022-04-27 16:04 ` Catalin Marinas
2022-04-28 2:22 ` Leizhen
2022-04-28 3:40 ` Baoquan He
2022-04-28 3:52 ` Baoquan He
2022-04-28 9:33 ` Leizhen
2022-04-29 3:24 ` Baoquan He
2022-04-29 8:02 ` Leizhen
2022-04-29 8:25 ` Leizhen
2022-05-03 22:00 ` Catalin Marinas
2022-05-05 2:13 ` Leizhen
2022-05-05 3:00 ` Baoquan He
2022-05-05 14:20 ` Catalin Marinas [this message]
2022-05-06 11:39 ` Baoquan He
2022-04-14 11:57 ` [PATCH v22 6/9] arm64: kdump: Use page-level mapping for the high memory of crashkernel Zhen Lei
2022-04-14 11:57 ` [PATCH v22 7/9] arm64: kdump: Try not to use NO_BLOCK_MAPPINGS for memory under 4G Zhen Lei
2022-04-14 11:57 ` [PATCH v22 8/9] of: fdt: Add memory for devices by DT property "linux, usable-memory-range" Zhen Lei
2022-04-14 11:57 ` [PATCH v22 9/9] docs: kdump: Update the crashkernel description for arm64 Zhen Lei
2022-04-19 17:02 ` [PATCH v22 0/9] support reserving crashkernel above 4G on arm64 kdump Dave Kleikamp
2022-04-25 2:19 ` Leizhen
2022-04-25 2:45 ` Baoquan He
2022-04-25 6:29 ` Leizhen
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=YnPdIvOktZBQYLjg@arm.com \
--to=catalin.marinas@arm.com \
--cc=kexec@lists.infradead.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