[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZB6OYjP5ODkSwaUx@kernel.org>
Date: Sat, 25 Mar 2023 09:02:10 +0300
From: Mike Rapoport <rppt@...nel.org>
To: Baoquan He <bhe@...hat.com>
Cc: linux-kernel@...r.kernel.org, catalin.marinas@....com,
horms@...nel.org, thunder.leizhen@...wei.com,
John.p.donnelly@...cle.com, will@...nel.org,
kexec@...ts.infradead.org, ardb@...nel.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 0/3] arm64: kdump : take off the protection on
crashkernel memory region
On Fri, Mar 24, 2023 at 09:18:35PM +0800, Baoquan He wrote:
> Problem:
> =======
> On arm64, block and section mapping is supported to build page tables.
> However, currently it enforces to take base page mapping for the whole
> linear mapping if CONFIG_ZONE_DMA or CONFIG_ZONE_DMA32 is enabled and
> crashkernel kernel parameter is set. This will cause longer time of the
> linear mapping process during bootup and severe performance degradation
> during running time.
>
> Root cause:
> ==========
> On arm64, crashkernel reservation relies on knowing the upper limit of
> low memory zone because it needs to reserve memory in the zone so that
> devices' DMA addressing in kdump kernel can be satisfied. However, the
> upper limit of low memory on arm64 is variant. And the upper limit can
> only be decided late till bootmem_init() is called [1].
>
> And we need to map the crashkernel region with base page granularity when
> doing linear mapping, because kdump needs to protect the crashkernel region
> via set_memory_valid(,0) after kdump kernel loading. However, arm64 doesn't
> support well on splitting the built block or section mapping due to some
> cpu reststriction [2]. And unfortunately, the linear mapping is done before
> bootmem_init().
>
> To resolve the above conflict on arm64, the compromise is enforcing to
> take base page mapping for the entire linear mapping if crashkernel is
> set, and CONFIG_ZONE_DMA or CONFIG_ZONE_DMA32 is enabed. Hence
> performance is sacrificed.
>
> Solution:
> =========
> Comparing with the always encountered base page mapping for the whole
> linear region, it's better to take off the protection on crashkernel memory
> region for now because the protection can only happen in a chance in one
> million, while the base page mapping for the whole linear mapping is
> always mitigating arm64 systems with crashkernel set.
>
> This can let distros have chance to back port this patchset to fix the
> performance issue caused by the base page mapping in the whole linear
> region.
>
> Extra words
> ===========
> I personally expect that we can add these back in the near future
> when arm64_dma_phys_limit is fixed, e.g Raspberry Pi enlarges the device
> addressing limit to 32bit; or Arm64 can support splitting built block or
> section mapping. Like this, the code is the simplest and clearest.
>
> Or as Catalin suggested, for below 4 cases we currently defer to handle
> in bootme_init(), we can try to handle case 3) in advance so that memory
> above 4G can avoid base page mapping wholly. This will complicate the
> already complex code, let's see how it looks if people interested post patch.
>
> crashkernel=size
> 1)first attempt: low memory under arm64_dma_phys_limit
> 2)fallback: finding memory above 4G
>
> crashkernel=size,high
> 3)first attempt: finding memory above 4G
> 4)fallback: low memory under arm64_dma_phys_limit
>
>
> [1]
> https://lore.kernel.org/all/YrIIJkhKWSuAqkCx@arm.com/T/#u
>
> [2]
> https://lore.kernel.org/linux-arm-kernel/20190911182546.17094-1-nsaenzjulienne@suse.de/T/
>
> Baoquan He (3):
> arm64: kdump : take off the protection on crashkernel memory region
> arm64: kdump: do not map crashkernel region specifically
> arm64: kdump: defer the crashkernel reservation for platforms with no
> DMA memory zones
>
> arch/arm64/include/asm/kexec.h | 6 -----
> arch/arm64/include/asm/memory.h | 5 ----
> arch/arm64/kernel/machine_kexec.c | 20 --------------
> arch/arm64/mm/init.c | 6 +----
> arch/arm64/mm/mmu.c | 43 -------------------------------
> 5 files changed, 1 insertion(+), 79 deletions(-)
Acked-by: Mike Rapoport (IBM) <rppt@...nel.org>
> --
> 2.34.1
>
--
Sincerely yours,
Mike.
Powered by blists - more mailing lists