| Message ID | 20220711090319.1604-1-thunder.leizhen@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: kdump: Function supplement and performance optimization | expand |
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://lkml.org/lkml/2022/5/6/428) 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 '@offset', 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? 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 >
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://lkml.org/lkml/2022/5/6/428) 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 '@offset', 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 >> > > . >
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 '@offset', 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.
On 10/06/22 at 09:55am, john.p.donnelly@oracle.com wrote: > On 8/1/22 9:47 PM, Leizhen (ThunderTown) wrote: ...... > > > 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. > > > > > > 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. This change is located in arch/arm64 folder, I have pinged arm64 maintainer to consider merging this patchset. Not sure if they are still thinking, or ignore this. Hi Catalin, Will, Ping again! Do you have plan to accept this patchset? It's very important for crashkernel setting on arm64 with a simple and default syntax. Thanks Baoquan
On 10/13/22 05:46, Baoquan He wrote: > On 10/06/22 at 09:55am, john.p.donnelly@oracle.com wrote: >> On 8/1/22 9:47 PM, Leizhen (ThunderTown) wrote: > ...... >>>> 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. >>>> >>> >> 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. > > This change is located in arch/arm64 folder, I have pinged arm64 > maintainer to consider merging this patchset. Not sure if they are > still thinking, or ignore this. > > Hi Catalin, Will, > > Ping again! > > Do you have plan to accept this patchset? It's very important fo > crashkernel setting on arm64 with a simple and default syntax. > > Thanks > Baoquan > Hi, We have pulled this into our Linux 6.0.0 QA test kernels for now. We would like it added too. Thank you, John
On Thu, Oct 13, 2022 at 06:46:35PM +0800, Baoquan He wrote: > On 10/06/22 at 09:55am, john.p.donnelly@oracle.com wrote: > > 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. > > This change is located in arch/arm64 folder, I have pinged arm64 > maintainer to consider merging this patchset. Not sure if they are > still thinking, or ignore this. > > Hi Catalin, Will, > > Ping again! > > Do you have plan to accept this patchset? It's very important for > crashkernel setting on arm64 with a simple and default syntax. I'll look at it once the merging window closes. I saw discussions on this thread and I ignored it until you all agreed ;).
On 10/14/22 11:29 AM, Catalin Marinas wrote: > On Thu, Oct 13, 2022 at 06:46:35PM +0800, Baoquan He wrote: >> On 10/06/22 at 09:55am, john.p.donnelly@oracle.com wrote: >>> 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. >> >> This change is located in arch/arm64 folder, I have pinged arm64 >> maintainer to consider merging this patchset. Not sure if they are >> still thinking, or ignore this. >> >> Hi Catalin, Will, >> >> Ping again! >> >> Do you have plan to accept this patchset? It's very important for >> crashkernel setting on arm64 with a simple and default syntax. > > I'll look at it once the merging window closes. I saw discussions on > this thread and I ignored it until you all agreed ;). > Hi, Do you have a timeline for this ? This crashkernel > 4G for Arm item has been lingering for 3 years. I think it is time for it to be incorporated. Thanks, John.
On Mon, Jul 11, 2022 at 05:03:17PM +0800, Zhen Lei wrote: > v2 --> v3: > 1. Discard patch 3 in v2, a cleanup patch. Do you plan to respin this series, addressing the various comments on v3? Will
On 2022/11/15 19:58, Will Deacon wrote: > On Mon, Jul 11, 2022 at 05:03:17PM +0800, Zhen Lei wrote: >> v2 --> v3: >> 1. Discard patch 3 in v2, a cleanup patch. > > Do you plan to respin this series, addressing the various comments on v3? Yes, I haven't figured out where to make DEFAULT_CRASH_KERNEL_LOW_SIZE generic. > > Will > . >
On Tue, Nov 15, 2022 at 08:18:21PM +0800, Leizhen (ThunderTown) wrote: > On 2022/11/15 19:58, Will Deacon wrote: > > On Mon, Jul 11, 2022 at 05:03:17PM +0800, Zhen Lei wrote: > >> v2 --> v3: > >> 1. Discard patch 3 in v2, a cleanup patch. > > > > Do you plan to respin this series, addressing the various comments on v3? > > Yes, I haven't figured out where to make DEFAULT_CRASH_KERNEL_LOW_SIZE generic. Do we need to? I'd just go with something like 128MB, specific to arm64, and we can increase it later if anyone comes up with a good argument.
On 2022/11/15 21:30, Catalin Marinas wrote: > On Tue, Nov 15, 2022 at 08:18:21PM +0800, Leizhen (ThunderTown) wrote: >> On 2022/11/15 19:58, Will Deacon wrote: >>> On Mon, Jul 11, 2022 at 05:03:17PM +0800, Zhen Lei wrote: >>>> v2 --> v3: >>>> 1. Discard patch 3 in v2, a cleanup patch. >>> >>> Do you plan to respin this series, addressing the various comments on v3? >> >> Yes, I haven't figured out where to make DEFAULT_CRASH_KERNEL_LOW_SIZE generic. > > Do we need to? I'd just go with something like 128MB, specific to arm64, > and we can increase it later if anyone comes up with a good argument. Okay, then v3's easy. I'll do it tomorrow. I've tried it before. 128M is enough. >
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://lkml.org/lkml/2022/5/6/428) 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 '@offset', 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. 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(-)