Re: [PATCH v17 02/10] x86: kdump: make the lower bound of crash kernel reservation consistent

On Wed, Dec 15, 2021 at 11:42:19AM +0800, Baoquan He wrote:

On 12/14/21 at 07:24pm, Catalin Marinas wrote:

quoted

On Tue, Dec 14, 2021 at 08:07:58PM +0100, Borislav Petkov wrote:

quoted

On Fri, Dec 10, 2021 at 02:55:25PM +0800, Zhen Lei wrote:

quoted

From: Chen Zhou <redacted>

The lower bounds of crash kernel reservation and crash kernel low
reservation are different, use the consistent value CRASH_ALIGN.

A big WHY is missing here to explain why the lower bound of the
allocation range needs to be 16M and why was 0 wrong?

I asked the same here:

https://lore.kernel.org/r/20210224143547.GB28965@arm.com (local)

IIRC Baoquan said that there is a 1MB reserved for x86 anyway in the
lower part, so that's equivalent in practice to starting from
CRASH_ALIGN.

Yeah, even for i386, there's area reserved by BIOS inside low 1M.
Considering the existing alignment CRASH_ALIGN which is 16M, we
definitely have no chance to get memory starting from 0. So starting
from 16M can skip the useless memblock searching, and make the
crashkernel low reservation consisten with crashkernel reservation on
allocation code.

That's the x86 assumption. Is it valid for other architectures once the
code has been made generic in patch 6? It should be ok for arm64, RAM
tends to start from higher up but other architectures may start using
this common code.

If you want to keep the same semantics as before, just leave it as 0.
It's not that the additional lower bound makes the search slower.

-- 
Catalin