[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1d89e2cb-de26-0f85-7a2a-f68599a1b143@oracle.com>
Date: Thu, 6 Oct 2022 09:55:35 -0500
From: john.p.donnelly@...cle.com
To: "Leizhen (ThunderTown)" <thunder.leizhen@...wei.com>,
Baoquan He <bhe@...hat.com>
Cc: Dave Young <dyoung@...hat.com>, Vivek Goyal <vgoyal@...hat.com>,
kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
linux-arm-kernel@...ts.infradead.org,
Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
"Eric W . Biederman" <ebiederm@...ssion.com>,
Randy Dunlap <rdunlap@...radead.org>,
Feng Zhou <zhoufeng.zf@...edance.com>,
Kefeng Wang <wangkefeng.wang@...wei.com>,
Chen Zhou <dingguo.cz@...group.com>,
Dave Kleikamp <dave.kleikamp@...cle.com>,
John Donnelly <john.p.donnelly@...cle.com>,
"samasth.norway.ananda" <samasth.norway.ananda@...cle.com>
Subject: Re: [PATCH v3 0/2] arm64: kdump: Function supplement and performance
optimization
On 8/1/22 9:47 PM, Leizhen (ThunderTown) wrote:
>
>
> On 2022/8/1 16:20, Baoquan He wrote:
>> Hi Catalin,
>>
>> On 07/11/22 at 05:03pm, Zhen Lei wrote:
>>> v2 --> v3:
>>> 1. Discard patch 3 in v2, a cleanup patch.
>>>
>>> v1 --> v2:
>>> 1. Update the commit message of Patch 1, explicitly indicates that "crashkernel=X,high"
>>> is specified but "crashkernel=Y,low" is not specified.
>>> 2. Drop Patch 4-5. Currently, focus on function integrity, performance optimization
>>> will be considered in later versions.
>>> 3. Patch 3 is not mandatory, it's just a cleanup now, although it is a must for patch 4-5.
>>> But to avoid subsequent duplication of effort, I'm glad it was accepted.
>>>
>>>
>>> v1:
>>> After the basic functions of "support reserving crashkernel above 4G on arm64
>>> kdump"(see https://urldefense.com/v3/__https://lkml.org/lkml/2022/5/6/428__;!!ACWV5N9M2RV99hQ!ORBFa4UAmMss_79nuwu1kpW3D-mTela240vFo0FXOuV9QpGWy7Fp2H81ZjLPOuaufAQC_XBFEFGjAqs5njfGS6Rd4dZLhaez$ ) are implemented, we still have
>>> three features to be improved.
>>> 1. When crashkernel=X,high is specified but crashkernel=Y,low is not specified,
>>> the default crash low memory size is provided.
>>> 2. For crashkernel=X without '@...set', if the low memory fails to be allocated,
>>> fall back to reserve region from high memory(above DMA zones).
>>> 3. If crashkernel=X,high is used, page mapping is performed only for the crash
>>> high memory, and block mapping is still used for other linear address spaces.
>>> Compared to the previous version:
>>> (1) For crashkernel=X[@offset], the memory above 4G is not changed to block
>>> mapping, leave it to the next time.
>>> (2) The implementation method is modified. Now the implementation is simpler
>>> and clearer.
>>
>> Do you have plan to pick this series so that it can be taken into 5.20
>> rc-1~3?
>
> Hi, Catalin:
> Only function reserve_crashkernel() is modified in these two patches. The core
> process of the arm64 architecture is not affected. I remember you suggested that
> arm64 and x86 share the same kdump code, so these two subfeatures are needed.
> Maybe we can lay the foundation first for the people who build the road. Unifying
> the external interfaces of kdump on arm64 and x86 does not seem to hurt.
>
>
>>
>> We have back ported the basic crashkernel=high, low, support into our
>> distros and have taken wide testing on arm64 servers, need this patchset
>> to back port for more testing.
>>
>> Thanks
>> Baoquan
>>
>>>
>>> Zhen Lei (2):
>>> arm64: kdump: Provide default size when crashkernel=Y,low is not
>>> specified
>>> arm64: kdump: Support crashkernel=X fall back to reserve region above
>>> DMA zones
>>>
>>> .../admin-guide/kernel-parameters.txt | 10 ++-----
>>> arch/arm64/mm/init.c | 28 +++++++++++++++++--
>>> 2 files changed, 28 insertions(+), 10 deletions(-)
>>>
>>> --
>>> 2.25.1
>>>
>>
>> .
>>
>
Hi ,
What is the progress of this series ?
Without this patch set we are seeing larger crashkernel=896M failures
on Arm with Linux-6.0.rc7. This larger value is needed for
iSCSI booted systems with certain network adapters.
Thank you,
John.
Powered by blists - more mailing lists