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(-)
--
2.25.1
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
>>
>
> .
>
--
Regards,
Zhen Lei
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, [email protected] 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, [email protected] 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, [email protected] 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 ;).
--
Catalin
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, [email protected] 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
> .
>
--
Regards,
Zhen Lei
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.
--
Catalin
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.
>
--
Regards,
Zhen Lei