All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: will@kernel.org, corbet@lwn.net, paul.walmsley@sifive.com,
	palmer@dabbelt.com, aou@eecs.berkeley.edu,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH -next] arm64/kdump: Update the high memory reserve doc
Date: Tue, 6 Aug 2024 17:59:22 +0100	[thread overview]
Message-ID: <ZrJWarQnhFiM-e17@arm.com> (raw)
In-Reply-To: <20240806113320.2388386-1-ruanjinjie@huawei.com>

On Tue, Aug 06, 2024 at 07:33:20PM +0800, Jinjie Ruan wrote:
> Since commit 282c3a66b724 ("crash: Fix riscv64 crash memory reserve dead
> loop"), if reservation from the high memory failed on ARM64, the kernel
> will not falls back to searching the low memory, so remove it in the doc.

This commit doesn't exist in -next. I found it with a different hash but
don't add it in the commit log here.

> diff --git a/Documentation/arch/arm64/kdump.rst b/Documentation/arch/arm64/kdump.rst
> index 56a89f45df28..11b9b84bf422 100644
> --- a/Documentation/arch/arm64/kdump.rst
> +++ b/Documentation/arch/arm64/kdump.rst
> @@ -79,10 +79,6 @@ To reserve memory for crashkernel=size,high, searching is first
>  attempted from the high memory region. If the reservation succeeds, the
>  low memory reservation will be done subsequently.
>  
> -If reservation from the high memory failed, the kernel falls back to
> -searching the low memory with the specified size in crashkernel=,high.
> -If it succeeds, no further reservation for low memory is needed.

I recall long discussions over a year ago where the conclusion was that
for sysadmins it's easier to have crashkernel=,high the default with
fallback to lowmem. No need to worry about how much low or high memory
there is on a SoC, just specify a preference for high memory.

Can we not have a different fix for the infinite loop problem while we
preserve the fallback behaviour?

-- 
Catalin

  reply	other threads:[~2024-08-06 16:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-06 11:33 [PATCH -next] arm64/kdump: Update the high memory reserve doc Jinjie Ruan
2024-08-06 16:59 ` Catalin Marinas [this message]
2024-08-07  1:46   ` Jinjie Ruan

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=ZrJWarQnhFiM-e17@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=corbet@lwn.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=ruanjinjie@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 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.