[PATCH -next] arm64/kdump: Update the high memory reserve doc

[PATCH -next] arm64/kdump: Update the high memory reserve doc

[Jinjie Ruan]

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.

Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
 Documentation/arch/arm64/kdump.rst | 4 ----
 1 file changed, 4 deletions(-)

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.
-
 Notes:
 
 - If crashkernel=,low is not specified, the default low memory
-- 
2.34.1

Re: [PATCH -next] arm64/kdump: Update the high memory reserve doc

[Catalin Marinas]

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

Re: [PATCH -next] arm64/kdump: Update the high memory reserve doc

[Jinjie Ruan]

On 2024/8/7 0:59, Catalin Marinas wrote:
> 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?

Of course, thank you!

>