From: Catalin Marinas <catalin.marinas@arm.com>
To: Baoquan He <bhe@redhat.com>
Cc: linux-kernel@vger.kernel.org, horms@kernel.org,
thunder.leizhen@huawei.com, John.p.donnelly@oracle.com,
will@kernel.org, kexec@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4] arm64: kdump: simplify the reservation behaviour of crashkernel=,high
Date: Thu, 16 Mar 2023 17:35:00 +0000 [thread overview]
Message-ID: <ZBNTRBqqb74T3RMx@arm.com> (raw)
In-Reply-To: <ZBLlyGxGk33yrA+2@MiWiFi-R3L-srv>
On Thu, Mar 16, 2023 at 05:47:52PM +0800, Baoquan He wrote:
> On 03/15/23 at 02:52pm, Catalin Marinas wrote:
> > On Mon, Mar 06, 2023 at 04:41:24PM +0800, Baoquan He wrote:
> > > + /*
> > > + * For crashkernel=size[KMG], if the first attempt was for
> > > + * low memory, fall back to high memory, the minimum required
> > > + * low memory will be reserved later.
> > > + */
> > > + if (!high && crash_max == CRASH_ADDR_LOW_MAX) {
> > > crash_max = CRASH_ADDR_HIGH_MAX;
> > > + search_base = CRASH_ADDR_LOW_MAX;
> > > crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
> > > goto retry;
> > > }
> >
> > So I'm more tempted to set the search_base to 4G here rather than
> > CRASH_ADDR_LOW_MAX. The crashkernel=x,high option on a RPi4 with all
> > memory below 4G will fall back to low allocation. But RPi4 is the odd
> > one out, so I think we can live with this.
>
> I totally agree with you that we should take 4G as the fixed boundary of
> low and high memory because kdump is aimed at workstation and server
> platform. We can leave RPi4 to use crashkernel=size[KMG][@offset[KMG]]
> to specify a region if people have to use.
>
> [PATCH 0/2] arm64, kdump: enforce to take 4G as the crashkernel low memory end
> https://lore.kernel.org/all/20220828005545.94389-1-bhe@redhat.com/T/#u
>
> Now I am wondering if we should change CRASH_ADDR_LOW_MAX to 4G directly
> since we decide to take 4G as the low memory limit when doing 'high'
> reserving or falling back. This is just like what we have been doing in
> x86_64. Not sure if I follow you correctly.
On RPi4, we do need the 'low' allocation to be below 1GB, otherwise
ZONE_DMA will be empty. But we can leave the 'high' reservation above
4GB (if available). The downside is that we won't get anything between
1GB and 4GB unless explicitly specified with @offset.
I'm not entirely sure what you want to achieve: avoiding the 'high'
reservation going across an arbitrary boundary (1GB or 4GB) that the
user may not be aware of or just avoiding the 'high' reservation going
across a 4G boundary? On RPi4, if the 'high' reservation above 4GB
fails, should it fall back to below 1GB reservation or to somewhere
between 1GB and 4GB, making sure it doesn't cross any of these two
boundaries? For someone unfamiliar with the ZONE_DMA on RPi4, the latter
would look like two 'low' allocations below 4GB.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-03-16 17:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-06 8:41 [PATCH v4] arm64: kdump: simplify the reservation behaviour of crashkernel=,high Baoquan He
2023-03-06 12:55 ` Leizhen (ThunderTown)
2023-03-08 11:02 ` Simon Horman
2023-03-15 14:52 ` Catalin Marinas
2023-03-16 9:47 ` Baoquan He
2023-03-16 17:35 ` Catalin Marinas [this message]
2023-03-17 15:09 ` Baoquan He
2023-03-17 18:05 ` Catalin Marinas
2023-03-20 13:12 ` Baoquan He
2023-03-23 17:25 ` Catalin Marinas
2023-03-24 2:47 ` Leizhen (ThunderTown)
2023-03-24 14:53 ` Baoquan He
2023-03-25 1:53 ` Leizhen (ThunderTown)
2023-03-24 14:08 ` Baoquan He
2023-03-24 17:08 ` Catalin Marinas
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=ZBNTRBqqb74T3RMx@arm.com \
--to=catalin.marinas@arm.com \
--cc=John.p.donnelly@oracle.com \
--cc=bhe@redhat.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 NNTP newsgroup(s).