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: Fri, 24 Mar 2023 17:08:32 +0000 [thread overview]
Message-ID: <ZB3ZEBRKlCI9WIgK@arm.com> (raw)
In-Reply-To: <ZB2u0QAEU1P7qIZc@MiWiFi-R3L-srv>
On Fri, Mar 24, 2023 at 10:08:17PM +0800, Baoquan He wrote:
> On 03/23/23 at 05:25pm, Catalin Marinas wrote:
> > On Mon, Mar 20, 2023 at 09:12:08PM +0800, Baoquan He wrote:
> > > crashkernel=size
> > > 1)first attempt: low memory under arm64_dma_phys_limit
> > > 2)fallback: finding memory above 4G
> >
> > (2) should be 'finding memory above arm64_dma_phys_limit' to keep the
> > current behaviour for RPi4.
>
> Then for RPi4, with case 2), it will find memory above
> arm64_dma_phys_limit, namely 1G. Then it will get two memory regions,
> one could be in [1G, 4G], another is below 4G. I am fine with this, as
> long as it won't cause confusion that people may think two low memory
> regions you mentioned earlier. Please help confirm if I understand your
> suggestioin correctly. I will start making patch with this clarified.
Yes, you understood correctly. While it may still be slightly confusing,
if the user is not specific about high and low on the cmdline, we just
allow the kernel to find the best places. I assume distros will just use
,high and get a consistent behaviour on all platforms.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2023-03-24 17:09 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
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 [this message]
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=ZB3ZEBRKlCI9WIgK@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).