On 2020/9/4 12:16, Dave Young wrote:

On 09/04/20 at 12:02pm, chenzhou wrote:

quoted

On 2020/9/4 11:10, Dave Young wrote:

quoted

On 09/04/20 at 11:04am, Dave Young wrote:

quoted

On 09/03/20 at 07:26pm, chenzhou wrote:

quoted

Hi Catalin,


On 2020/9/3 1:09, Catalin Marinas wrote:

quoted

On Sat, Aug 01, 2020 at 09:08:54PM +0800, Chen Zhou wrote:

quoted

There are following issues in arm64 kdump:
1. We use crashkernel=X to reserve crashkernel below 4G, which
will fail when there is no enough low memory.
2. If reserving crashkernel above 4G, in this case, crash dump
kernel will boot failure because there is no low memory available
for allocation.
3. Since commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32"),
if the memory reserved for crash dump kernel falled in ZONE_DMA32,
the devices in crash dump kernel need to use ZONE_DMA will alloc
fail.

To solve these issues, change the behavior of crashkernel=X.
crashkernel=X tries low allocation in ZONE_DMA, and fall back to
high allocation if it fails.

If requized size X is too large and leads to very little free memory
in ZONE_DMA after low allocation, the system may not work normally.
So add a threshold and go for high allocation directly if the required
size is too large. The value of threshold is set as the half of
the low memory.

If crash_base is outside ZONE_DMA, try to allocate at least 256M in
ZONE_DMA automatically. "crashkernel=Y,low" can be used to allocate
specified size low memory.

Except for the threshold to keep zone ZONE_DMA memory,
reserve_crashkernel() looks very close to the x86 version. Shall we try
to make this generic as well? In the first instance, you could avoid the
threshold check if it takes an explicit ",high" option.

Ok, i will try to do this.

I look into the function reserve_crashkernel() of x86 and found the start address is
CRASH_ALIGN in function memblock_find_in_range(), which is different with arm64.

I don't figure out why is CRASH_ALIGN in x86, is there any specific reason?

Hmm, took another look at the option CONFIG_PHYSICAL_ALIGN
config PHYSICAL_ALIGN
        hex "Alignment value to which kernel should be aligned"
        default "0x200000"
        range 0x2000 0x1000000 if X86_32
        range 0x200000 0x1000000 if X86_64

According to above, I think the 16M should come from the largest value
But the default value is 2M,  with smaller value reservation can have
more chance to succeed.

It seems we still need arch specific CRASH_ALIGN, but the initial
version you added the #ifdef for different arches, can you move the
macro to arch specific headers?

And just keep the x86 align value as is, I can try to change the x86
value later to CONFIG_PHYSICAL_ALIGN, in this way this series can be
cleaner.

Ok. I have no question about the value of macro CRASH_ALIGN,
instead the lower bound of memblock_find_in_range().

For x86, in reserve_crashkernel()，restrict the lower bound of the range to CRASH_ALIGN,
    ...
    crash_base = memblock_find_in_range(CRASH_ALIGN,
                                                CRASH_ADDR_LOW_MAX,
                                                crash_size, CRASH_ALIGN);
    ...
   
in reserve_crashkernel_low()，with no this restriction.
    ...
    low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
    ...

How about all making memblock_find_in_range() search from the start of memory?
If it is ok, i will do like this in the generic version.

I feel starting with CRASH_ALIGN sounds better, can you just search from
CRASH_ALIGN in generic version?

ok.

Thanks
Dave


.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel