[lkml]   [2019]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/3] support reserving crashkernel above 4G on arm64 kdump
Hi Chen,

Thanks for the patchset.

Before I review the patches in detail, I have a couple of generic
queries. Please see them in-line:

On 04/03/2019 11:05 AM, Chen Zhou wrote:
> When crashkernel is reserved above 4G in memory, kernel should reserve
> some amount of low memory for swiotlb and some DMA buffers. So there may
> be two crash kernel regions, one is below 4G, the other is above 4G.
> Crash dump kernel reads more than one crash kernel regions via a dtb
> property under node /chosen,
> linux,usable-memory-range = <BASE1 SIZE1 [BASE2 SIZE2]>.
> Besides, we need to modify kexec-tools:
> arm64: support more than one crash kernel regions
> Chen Zhou (3):
> arm64: kdump: support reserving crashkernel above 4G
> arm64: kdump: support more than one crash kernel regions
> kdump: update Documentation about crashkernel on arm64
> Documentation/admin-guide/kernel-parameters.txt | 4 +-
> arch/arm64/kernel/setup.c | 3 +
> arch/arm64/mm/init.c | 108 ++++++++++++++++++++----
> include/linux/memblock.h | 1 +
> mm/memblock.c | 40 +++++++++
> 5 files changed, 139 insertions(+), 17 deletions(-)

I am wondering about the use-case for the same. I remember normally
fedora-based arm64 systems can do well with a maximum crashkernel size
of <=512MB reserved below the 4G boundary.

So, do you mean that for your use-case (may be a huawei board based
setup?), you need:

- more than 512MB of crashkernel size, or
- you want to split the crashkernel reservation across the 4GB boundary
irrespective of the crashkernel size value.


 \ /
  Last update: 2019-04-09 07:20    [W:0.090 / U:10.852 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site