linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Chen Zhou <chenzhou10@huawei.com>
Cc: will@kernel.org, james.morse@arm.com, tglx@linutronix.de,
	mingo@redhat.com, dyoung@redhat.com, bhe@redhat.com,
	corbet@lwn.net, John.P.donnelly@oracle.com,
	prabhakar.pkin@gmail.com, bhsharma@redhat.com,
	horms@verge.net.au, robh+dt@kernel.org, arnd@arndb.de,
	nsaenzjulienne@suse.de, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
	linux-doc@vger.kernel.org, guohanjun@huawei.com,
	xiexiuqi@huawei.com, huawei.libin@huawei.com,
	wangkefeng.wang@huawei.com
Subject: Re: [PATCH v11 3/5] arm64: kdump: reimplement crashkernel=X
Date: Wed, 2 Sep 2020 18:09:11 +0100	[thread overview]
Message-ID: <20200902170910.GB16673@gaia> (raw)
In-Reply-To: <20200801130856.86625-4-chenzhou10@huawei.com>

On Sat, Aug 01, 2020 at 09:08:54PM +0800, Chen Zhou wrote:
> There are following issues in arm64 kdump:
> 1. We use crashkernel=X to reserve crashkernel below 4G, which
> will fail when there is no enough low memory.
> 2. If reserving crashkernel above 4G, in this case, crash dump
> kernel will boot failure because there is no low memory available
> for allocation.
> 3. Since commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32"),
> if the memory reserved for crash dump kernel falled in ZONE_DMA32,
> the devices in crash dump kernel need to use ZONE_DMA will alloc
> fail.
> 
> To solve these issues, change the behavior of crashkernel=X.
> crashkernel=X tries low allocation in ZONE_DMA, and fall back to
> high allocation if it fails.
> 
> If requized size X is too large and leads to very little free memory
> in ZONE_DMA after low allocation, the system may not work normally.
> So add a threshold and go for high allocation directly if the required
> size is too large. The value of threshold is set as the half of
> the low memory.
> 
> If crash_base is outside ZONE_DMA, try to allocate at least 256M in
> ZONE_DMA automatically. "crashkernel=Y,low" can be used to allocate
> specified size low memory.

Except for the threshold to keep zone ZONE_DMA memory,
reserve_crashkernel() looks very close to the x86 version. Shall we try
to make this generic as well? In the first instance, you could avoid the
threshold check if it takes an explicit ",high" option.

-- 
Catalin

  reply	other threads:[~2020-09-02 17:09 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-01 13:08 [PATCH v11 0/5] support reserving crashkernel above 4G on arm64 kdump Chen Zhou
2020-08-01 13:08 ` [PATCH v11 1/5] arm64: kdump: add macro CRASH_ALIGN and CRASH_ADDR_LOW_MAX Chen Zhou
2020-08-01 13:08 ` [PATCH v11 2/5] x86: kdump: move reserve_crashkernel_low() into crash_core.c Chen Zhou
2020-08-06 13:36   ` Ingo Molnar
2020-09-01 16:50     ` Catalin Marinas
2020-08-08  9:59   ` Dave Young
2020-08-01 13:08 ` [PATCH v11 3/5] arm64: kdump: reimplement crashkernel=X Chen Zhou
2020-09-02 17:09   ` Catalin Marinas [this message]
2020-09-03 11:26     ` chenzhou
2020-09-03 13:18       ` chenzhou
2020-09-04  3:04       ` Dave Young
2020-09-04  3:10         ` Dave Young
2020-09-04  4:02           ` chenzhou
2020-09-04  4:16             ` Dave Young
2020-09-04  6:39               ` chenzhou
2020-08-01 13:08 ` [PATCH v11 4/5] arm64: kdump: add memory for devices by DT property linux,usable-memory-range Chen Zhou
2020-08-01 13:08 ` [PATCH v11 5/5] kdump: update Documentation about crashkernel Chen Zhou
2020-08-08 10:02   ` Dave Young
2020-08-10  3:28     ` chenzhou
2020-08-10  5:59       ` Dave Young
2020-08-10  6:03       ` Dave Young
2020-08-18  7:07         ` chenzhou
2020-08-19 12:03           ` Dave Young
2020-08-28  1:59             ` chenzhou
2020-09-01 17:13           ` Catalin Marinas
2020-09-02 16:42           ` Catalin Marinas
2020-09-02 17:13   ` Catalin Marinas
2020-09-03 11:56     ` chenzhou
2020-08-06 11:37 ` [PATCH v11 0/5] support reserving crashkernel above 4G on arm64 kdump Dave Young

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=20200902170910.GB16673@gaia \
    --to=catalin.marinas@arm.com \
    --cc=John.P.donnelly@oracle.com \
    --cc=arnd@arndb.de \
    --cc=bhe@redhat.com \
    --cc=bhsharma@redhat.com \
    --cc=chenzhou10@huawei.com \
    --cc=corbet@lwn.net \
    --cc=dyoung@redhat.com \
    --cc=guohanjun@huawei.com \
    --cc=horms@verge.net.au \
    --cc=huawei.libin@huawei.com \
    --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=mingo@redhat.com \
    --cc=nsaenzjulienne@suse.de \
    --cc=prabhakar.pkin@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=wangkefeng.wang@huawei.com \
    --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).