From: Chen Zhou <chenzhou10@huawei.com>
To: Dave Young <dyoung@redhat.com>, James Morse <james.morse@arm.com>
Cc: <tglx@linutronix.de>, <mingo@redhat.com>,
<catalin.marinas@arm.com>, <will@kernel.org>,
<bhsharma@redhat.com>, <horms@verge.net.au>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <kexec@lists.infradead.org>,
<linux-doc@vger.kernel.org>, <xiexiuqi@huawei.com>,
kbuild test robot <lkp@intel.com>
Subject: Re: [PATCH v7 1/4] x86: kdump: move reserve_crashkernel_low() into crash_core.c
Date: Fri, 3 Apr 2020 15:29:12 +0800 [thread overview]
Message-ID: <22a98ad8-e799-081d-7815-6c44bd18dedd@huawei.com> (raw)
In-Reply-To: <20200117035804.GA16926@dhcp-128-65.nay.redhat.com>
Hi Dave/James,
On 2020/1/17 11:58, Dave Young wrote:
> On 01/16/20 at 03:17pm, James Morse wrote:
>> Hi guys,
>>
>> On 28/12/2019 09:32, Dave Young wrote:
>>> On 12/27/19 at 07:04pm, Chen Zhou wrote:
>>>> On 2019/12/27 13:54, Dave Young wrote:
>>>>> On 12/23/19 at 11:23pm, Chen Zhou wrote:
>>>>>> In preparation for supporting reserve_crashkernel_low in arm64 as
>>>>>> x86_64 does, move reserve_crashkernel_low() into kernel/crash_core.c.
>>>>>>
>>>>>> Note, in arm64, we reserve low memory if and only if crashkernel=X,low
>>>>>> is specified. Different with x86_64, don't set low memory automatically.
>>>>>
>>>>> Do you have any reason for the difference? I'd expect we have same
>>>>> logic if possible and remove some of the ifdefs.
>>>>
>>>> In x86_64, if we reserve crashkernel above 4G, then we call reserve_crashkernel_low()
>>>> to reserve low memory.
>>>>
>>>> In arm64, to simplify, we call reserve_crashkernel_low() at the beginning of reserve_crashkernel()
>>>> and then relax the arm64_dma32_phys_limit if reserve_crashkernel_low() allocated something.
>>>> In this case, if reserve crashkernel below 4G there will be 256M low memory set automatically
>>>> and this needs extra considerations.
>>
>>> Sorry that I did not read the old thread details and thought that is
>>> arch dependent. But rethink about that, it would be better that we can
>>> have same semantic about crashkernel parameters across arches. If we
>>> make them different then it causes confusion, especially for
>>> distributions.
>>
>> Surely distros also want one crashkernel* string they can use on all platforms without
>> having to detect the kernel version, platform or changeable memory layout...
>>
>>
>>> OTOH, I thought if we reserve high memory then the low memory should be
>>> needed. There might be some exceptions, but I do not know the exact
>>> one,
>>
>>> can we make the behavior same, and special case those systems which
>>> do not need low memory reservation.
>>
>> Its tricky to work out which systems are the 'normal' ones.
>>
>> We don't have a fixed memory layout for arm64. Some systems have no memory below 4G.
>> Others have no memory above 4G.
>>
>> Chen Zhou's machine has some memory below 4G, but its too precious to reserve a large
>> chunk for kdump. Without any memory below 4G some of the drivers won't work.
>>
>> I don't see what distros can set as their default for all platforms if high/low are
>> mutually exclusive with the 'crashkernel=' in use today. How did x86 navigate this, ... or
>> was it so long ago?
>
> It is very rare for such machine without any low memory in X86, at least
> from what I know, so the current way just works fine.
>
> Since arm64 is quite different, I would agree with current way
> proposed in the patch, but a question is, for those arm64 systems how can
> admin know if low crashkernel memory is needed or not? and just skip the
> low reservation for machine with high memory installed only?
Specified size low memory is for crash dump kernel devices.
I think admin should know if there are devices needing low memory in crash dump kernel.
James, any suggestions?
Thanks,
Chen Zhou
>
>>
>> No one else has reported a problem with the existing placement logic, hence treating this
>> 'low' thing as the 'in addition' special case.
>>
>>
>>>> previous discusses:
>>>> https://lkml.org/lkml/2019/6/5/670
>>>> https://lkml.org/lkml/2019/6/13/229
>>>
>>> Another concern from James:
>>> "
>>> With both crashk_low_res and crashk_res, we end up with two entries in /proc/iomem called
>>> "Crash kernel". Because its sorted by address, and kexec-tools stops searching when it
>>> find "Crash kernel", you are always going to get the kernel placed in the lower portion.
>>> "
>>>
>>> The kexec-tools code is iterating all "Crash kernel" ranges and add them
>>> in an array. In X86 code, it uses the higher range to locate memory.
>>
>> Then my hurried reading of what the user-space code does was wrong!
>>
>> If kexec-tools places the kernel in the low region, there may not be enough memory left
>> for whatever purpose it was reserved for. This was the motivation for giving it a
>> different name.
>
> Agreed, it is still a potential problem though. Say we have both low
> and high reserved. Kdump kernel boots up, the kernel and drivers,
> applications will use memory, I'm not sure if there is a memory
> allocation policy to let them all use high mem first.. Anyway that is
> beyond the kexec-tools and resource name.
>
> Thanks
> Dave
>
>
> .
>
next prev parent reply other threads:[~2020-04-03 7:29 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-23 15:23 [PATCH v7 0/4] support reserving crashkernel above 4G on arm64 kdump Chen Zhou
2019-12-23 15:23 ` [PATCH v7 1/4] x86: kdump: move reserve_crashkernel_low() into crash_core.c Chen Zhou
2019-12-27 5:54 ` Dave Young
2019-12-27 11:04 ` Chen Zhou
2019-12-28 9:32 ` Dave Young
2019-12-31 1:39 ` Chen Zhou
2020-04-03 7:13 ` Chen Zhou
2020-01-16 15:17 ` James Morse
2020-01-16 15:47 ` John Donnelly
2020-02-24 15:25 ` John Donnelly
2020-03-02 1:29 ` Chen Zhou
2020-01-17 3:58 ` Dave Young
2020-04-03 7:29 ` Chen Zhou [this message]
2019-12-23 15:23 ` [PATCH v7 2/4] arm64: kdump: reserve crashkenel above 4G for crash dump kernel Chen Zhou
2020-03-05 10:13 ` Prabhakar Kushwaha
2020-03-07 11:06 ` Chen Zhou
2020-03-07 18:43 ` John Donnelly
2020-03-09 4:59 ` Prabhakar Kushwaha
2020-03-09 4:48 ` Prabhakar Kushwaha
2020-03-09 15:51 ` Prabhakar Kushwaha
2020-03-10 1:30 ` chenzhou
2020-03-10 17:08 ` Prabhakar Kushwaha
2020-03-11 1:44 ` chenzhou
[not found] ` <8a4e3fca-ef77-eb1b-0ec6-a158b7fe5c0c@Oracle.com>
[not found] ` <cf36f21a-6434-06ab-5b6c-e16cb526896d@gmail.com>
[not found] ` <d0bc6ba2-74c8-c083-097f-e1e5765ddca0@Oracle.com>
[not found] ` <E60A9E2C-AC74-49A6-9D3E-BDD4EF58287F@oracle.com>
2020-03-11 2:42 ` Prabhakar Kushwaha
2020-03-11 16:46 ` John Donnelly
2020-03-12 1:49 ` Prabhakar Kushwaha
2020-03-12 1:54 ` Prabhakar Kushwaha
2020-03-12 2:39 ` John Donnelly
2019-12-23 15:23 ` [PATCH v7 3/4] arm64: kdump: add memory for devices by DT property, low-memory-range Chen Zhou
2019-12-23 15:23 ` [PATCH v7 4/4] kdump: update Documentation about crashkernel on arm64 Chen Zhou
[not found] ` <52102118-9b61-5978-3213-062e9c758dcf@Oracle.com>
2020-02-24 15:18 ` [PATCH v7 0/4] support reserving crashkernel above 4G on arm64 kdump John Donnelly
2020-03-26 3:09 ` Chen Zhou
2020-05-19 10:21 ` Arnd Bergmann
2020-05-19 20:21 ` John Donnelly
2020-05-20 8:32 ` Bhupesh Sharma
2020-05-20 3:30 ` chenzhou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=22a98ad8-e799-081d-7815-6c44bd18dedd@huawei.com \
--to=chenzhou10@huawei.com \
--cc=bhsharma@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=dyoung@redhat.com \
--cc=horms@verge.net.au \
--cc=james.morse@arm.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=xiexiuqi@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).