All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: kexec@lists.infradead.org
Subject: [PATCH v22 5/9] arm64: kdump: Reimplement crashkernel=X
Date: Thu, 5 May 2022 15:20:18 +0100	[thread overview]
Message-ID: <YnPdIvOktZBQYLjg@arm.com> (raw)
In-Reply-To: <YnM9w69l5dbE+k15@MiWiFi-R3L-srv>

On Thu, May 05, 2022 at 11:00:19AM +0800, Baoquan He wrote:
> On 05/03/22 at 11:00pm, Catalin Marinas wrote:
> > So, to recap, IIUC you are fine with:
> > 
> > 	crashkernel=Y		- allocate within ZONE_DMA with fallback
> > 				  above with a default in ZONE_DMA (like
> > 				  x86, 256M or swiotlb size)
> 
>         Ack to this one.
> 
> 
> > 	crashkernel=Y,high	- allocate from above ZONE_DMA
> 
>         Not exactly. If there's only ZONE_DMA, crashkernel,high will
>         be reserved in ZONE_DMA, and crashkernel,low will be ignored.
>         Other than this, ack.

Yes, that's fine.

> > 	crashkernel=Y,low	- allocate within ZONE_DMA
> 
>         Ack to this one.
> > 
> > 'crashkernel' overrides the high and low while the latter two can be
> > passed independently.
> 
>         crashkernel=,high can be passed independently, then a crashkernel=,low
>         is needed implicitly. If people don't want crashkernel=,low
>         explicitly, crashkernel=0,low need be specified.

I find this complicating the interface. I don't know the background to
the x86 implementation but we diverge already on arm64 since we talk
about ZONE_DMA rather than 4G limit (though for most platforms these
would be the same).

I guess we could restate the difference between crashkernel= and
crashkernel=,high as the hint to go for allocation above ZONE_DMA first.

>         An independent crashkernel=,low makes no sense. Crashkernel=,low
>         should be paird with crashkernel=,high.

You could argue that crashkernel=,low gives the current crashkernel=
behaviour, i.e. either all within ZONE_DMA or fail to allocate. So it
may have some value on its own.

>         My personal opinion according to the existed senmantics on x86.
>         Otherwise, the guidance of crashkernel= |,high|,low reservation
>         will be complicated to write.

It's more that I find the current semantics unnecessarily confusing. But
even reading the x86_64 text it's not that clear. For example the
default low allocation for crashkernel= and crashkernel=,high is only
mentioned in the crashkernel=,low description.

-- 
Catalin


WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Baoquan He <bhe@redhat.com>
Cc: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, Dave Young <dyoung@redhat.com>,
	Vivek Goyal <vgoyal@redhat.com>,
	Eric Biederman <ebiederm@xmission.com>,
	kexec@lists.infradead.org, Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	devicetree@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	linux-doc@vger.kernel.org, Randy Dunlap <rdunlap@infradead.org>,
	Feng Zhou <zhoufeng.zf@bytedance.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Chen Zhou <dingguo.cz@antgroup.com>,
	John Donnelly <John.p.donnelly@oracle.com>,
	Dave Kleikamp <dave.kleikamp@oracle.com>
Subject: Re: [PATCH v22 5/9] arm64: kdump: Reimplement crashkernel=X
Date: Thu, 5 May 2022 15:20:18 +0100	[thread overview]
Message-ID: <YnPdIvOktZBQYLjg@arm.com> (raw)
In-Reply-To: <YnM9w69l5dbE+k15@MiWiFi-R3L-srv>

On Thu, May 05, 2022 at 11:00:19AM +0800, Baoquan He wrote:
> On 05/03/22 at 11:00pm, Catalin Marinas wrote:
> > So, to recap, IIUC you are fine with:
> > 
> > 	crashkernel=Y		- allocate within ZONE_DMA with fallback
> > 				  above with a default in ZONE_DMA (like
> > 				  x86, 256M or swiotlb size)
> 
>         Ack to this one.
> 
> 
> > 	crashkernel=Y,high	- allocate from above ZONE_DMA
> 
>         Not exactly. If there's only ZONE_DMA, crashkernel,high will
>         be reserved in ZONE_DMA, and crashkernel,low will be ignored.
>         Other than this, ack.

Yes, that's fine.

> > 	crashkernel=Y,low	- allocate within ZONE_DMA
> 
>         Ack to this one.
> > 
> > 'crashkernel' overrides the high and low while the latter two can be
> > passed independently.
> 
>         crashkernel=,high can be passed independently, then a crashkernel=,low
>         is needed implicitly. If people don't want crashkernel=,low
>         explicitly, crashkernel=0,low need be specified.

I find this complicating the interface. I don't know the background to
the x86 implementation but we diverge already on arm64 since we talk
about ZONE_DMA rather than 4G limit (though for most platforms these
would be the same).

I guess we could restate the difference between crashkernel= and
crashkernel=,high as the hint to go for allocation above ZONE_DMA first.

>         An independent crashkernel=,low makes no sense. Crashkernel=,low
>         should be paird with crashkernel=,high.

You could argue that crashkernel=,low gives the current crashkernel=
behaviour, i.e. either all within ZONE_DMA or fail to allocate. So it
may have some value on its own.

>         My personal opinion according to the existed senmantics on x86.
>         Otherwise, the guidance of crashkernel= |,high|,low reservation
>         will be complicated to write.

It's more that I find the current semantics unnecessarily confusing. But
even reading the x86_64 text it's not that clear. For example the
default low allocation for crashkernel= and crashkernel=,high is only
mentioned in the crashkernel=,low description.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Baoquan He <bhe@redhat.com>
Cc: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, Dave Young <dyoung@redhat.com>,
	Vivek Goyal <vgoyal@redhat.com>,
	Eric Biederman <ebiederm@xmission.com>,
	kexec@lists.infradead.org, Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	devicetree@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	linux-doc@vger.kernel.org, Randy Dunlap <rdunlap@infradead.org>,
	Feng Zhou <zhoufeng.zf@bytedance.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Chen Zhou <dingguo.cz@antgroup.com>,
	John Donnelly <John.p.donnelly@oracle.com>,
	Dave Kleikamp <dave.kleikamp@oracle.com>
Subject: Re: [PATCH v22 5/9] arm64: kdump: Reimplement crashkernel=X
Date: Thu, 5 May 2022 15:20:18 +0100	[thread overview]
Message-ID: <YnPdIvOktZBQYLjg@arm.com> (raw)
In-Reply-To: <YnM9w69l5dbE+k15@MiWiFi-R3L-srv>

On Thu, May 05, 2022 at 11:00:19AM +0800, Baoquan He wrote:
> On 05/03/22 at 11:00pm, Catalin Marinas wrote:
> > So, to recap, IIUC you are fine with:
> > 
> > 	crashkernel=Y		- allocate within ZONE_DMA with fallback
> > 				  above with a default in ZONE_DMA (like
> > 				  x86, 256M or swiotlb size)
> 
>         Ack to this one.
> 
> 
> > 	crashkernel=Y,high	- allocate from above ZONE_DMA
> 
>         Not exactly. If there's only ZONE_DMA, crashkernel,high will
>         be reserved in ZONE_DMA, and crashkernel,low will be ignored.
>         Other than this, ack.

Yes, that's fine.

> > 	crashkernel=Y,low	- allocate within ZONE_DMA
> 
>         Ack to this one.
> > 
> > 'crashkernel' overrides the high and low while the latter two can be
> > passed independently.
> 
>         crashkernel=,high can be passed independently, then a crashkernel=,low
>         is needed implicitly. If people don't want crashkernel=,low
>         explicitly, crashkernel=0,low need be specified.

I find this complicating the interface. I don't know the background to
the x86 implementation but we diverge already on arm64 since we talk
about ZONE_DMA rather than 4G limit (though for most platforms these
would be the same).

I guess we could restate the difference between crashkernel= and
crashkernel=,high as the hint to go for allocation above ZONE_DMA first.

>         An independent crashkernel=,low makes no sense. Crashkernel=,low
>         should be paird with crashkernel=,high.

You could argue that crashkernel=,low gives the current crashkernel=
behaviour, i.e. either all within ZONE_DMA or fail to allocate. So it
may have some value on its own.

>         My personal opinion according to the existed senmantics on x86.
>         Otherwise, the guidance of crashkernel= |,high|,low reservation
>         will be complicated to write.

It's more that I find the current semantics unnecessarily confusing. But
even reading the x86_64 text it's not that clear. For example the
default low allocation for crashkernel= and crashkernel=,high is only
mentioned in the crashkernel=,low description.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-05-05 14:20 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-14 11:57 [PATCH v22 0/9] support reserving crashkernel above 4G on arm64 kdump Zhen Lei
2022-04-14 11:57 ` Zhen Lei
2022-04-14 11:57 ` Zhen Lei
2022-04-14 11:57 ` [PATCH v22 1/9] kdump: return -ENOENT if required cmdline option does not exist Zhen Lei
2022-04-14 11:57   ` Zhen Lei
2022-04-14 11:57   ` Zhen Lei
2022-04-25  3:49   ` Baoquan He
2022-04-25  3:49     ` Baoquan He
2022-04-25  3:49     ` Baoquan He
2022-04-14 11:57 ` [PATCH v22 2/9] arm64: Use insert_resource() to simplify code Zhen Lei
2022-04-14 11:57   ` Zhen Lei
2022-04-14 11:57   ` Zhen Lei
2022-04-14 11:57 ` [PATCH v22 3/9] arm64: kdump: Remove some redundant checks in map_mem() Zhen Lei
2022-04-14 11:57   ` Zhen Lei
2022-04-14 11:57   ` Zhen Lei
2022-04-14 11:57 ` [PATCH v22 4/9] arm64: kdump: Don't force page-level mappings for memory above 4G Zhen Lei
2022-04-14 11:57   ` Zhen Lei
2022-04-14 11:57   ` Zhen Lei
2022-04-26 14:26   ` Catalin Marinas
2022-04-26 14:26     ` Catalin Marinas
2022-04-26 14:26     ` Catalin Marinas
2022-04-27  7:12     ` Leizhen
2022-04-27  7:12       ` Leizhen (ThunderTown)
2022-04-27  7:12       ` Leizhen (ThunderTown)
2022-04-14 11:57 ` [PATCH v22 5/9] arm64: kdump: Reimplement crashkernel=X Zhen Lei
2022-04-14 11:57   ` Zhen Lei
2022-04-14 11:57   ` Zhen Lei
2022-04-26 18:02   ` Catalin Marinas
2022-04-26 18:02     ` Catalin Marinas
2022-04-26 18:02     ` Catalin Marinas
2022-04-27  6:54     ` Leizhen
2022-04-27  6:54       ` Leizhen (ThunderTown)
2022-04-27  6:54       ` Leizhen (ThunderTown)
2022-04-27 12:32       ` Catalin Marinas
2022-04-27 12:32         ` Catalin Marinas
2022-04-27 12:32         ` Catalin Marinas
2022-04-27 13:49         ` Leizhen
2022-04-27 13:49           ` Leizhen (ThunderTown)
2022-04-27 13:49           ` Leizhen (ThunderTown)
2022-04-27 16:04           ` Catalin Marinas
2022-04-27 16:04             ` Catalin Marinas
2022-04-27 16:04             ` Catalin Marinas
2022-04-28  2:22             ` Leizhen
2022-04-28  2:22               ` Leizhen (ThunderTown)
2022-04-28  2:22               ` Leizhen (ThunderTown)
2022-04-28  3:40             ` Baoquan He
2022-04-28  3:40               ` Baoquan He
2022-04-28  3:40               ` Baoquan He
2022-04-28  3:52               ` Baoquan He
2022-04-28  3:52                 ` Baoquan He
2022-04-28  3:52                 ` Baoquan He
2022-04-28  9:33                 ` Leizhen
2022-04-28  9:33                   ` Leizhen (ThunderTown)
2022-04-28  9:33                   ` Leizhen (ThunderTown)
2022-04-29  3:24                   ` Baoquan He
2022-04-29  3:24                     ` Baoquan He
2022-04-29  3:24                     ` Baoquan He
2022-04-29  8:02                     ` Leizhen
2022-04-29  8:02                       ` Leizhen (ThunderTown)
2022-04-29  8:02                       ` Leizhen (ThunderTown)
2022-04-29  8:25                       ` Leizhen
2022-04-29  8:25                         ` Leizhen (ThunderTown)
2022-04-29  8:25                         ` Leizhen (ThunderTown)
2022-05-03 22:00                         ` Catalin Marinas
2022-05-03 22:00                           ` Catalin Marinas
2022-05-03 22:00                           ` Catalin Marinas
2022-05-05  2:13                           ` Leizhen
2022-05-05  2:13                             ` Leizhen (ThunderTown)
2022-05-05  2:13                             ` Leizhen (ThunderTown)
2022-05-05  3:00                           ` Baoquan He
2022-05-05  3:00                             ` Baoquan He
2022-05-05  3:00                             ` Baoquan He
2022-05-05 14:20                             ` Catalin Marinas [this message]
2022-05-05 14:20                               ` Catalin Marinas
2022-05-05 14:20                               ` Catalin Marinas
2022-05-06 11:39                               ` Baoquan He
2022-05-06 11:39                                 ` Baoquan He
2022-05-06 11:39                                 ` Baoquan He
2022-04-14 11:57 ` [PATCH v22 6/9] arm64: kdump: Use page-level mapping for the high memory of crashkernel Zhen Lei
2022-04-14 11:57   ` Zhen Lei
2022-04-14 11:57   ` Zhen Lei
2022-04-14 11:57 ` [PATCH v22 7/9] arm64: kdump: Try not to use NO_BLOCK_MAPPINGS for memory under 4G Zhen Lei
2022-04-14 11:57   ` Zhen Lei
2022-04-14 11:57   ` Zhen Lei
2022-04-14 11:57 ` [PATCH v22 8/9] of: fdt: Add memory for devices by DT property "linux, usable-memory-range" Zhen Lei
2022-04-14 11:57   ` Zhen Lei
2022-04-14 11:57   ` [PATCH v22 8/9] of: fdt: Add memory for devices by DT property "linux,usable-memory-range" Zhen Lei
2022-04-14 11:57 ` [PATCH v22 9/9] docs: kdump: Update the crashkernel description for arm64 Zhen Lei
2022-04-14 11:57   ` Zhen Lei
2022-04-14 11:57   ` Zhen Lei
2022-04-19 17:02 ` [PATCH v22 0/9] support reserving crashkernel above 4G on arm64 kdump Dave Kleikamp
2022-04-19 17:02   ` Dave Kleikamp
2022-04-19 17:02   ` Dave Kleikamp
2022-04-25  2:19 ` Leizhen
2022-04-25  2:19   ` Leizhen (ThunderTown)
2022-04-25  2:19   ` Leizhen (ThunderTown)
2022-04-25  2:45   ` Baoquan He
2022-04-25  2:45     ` Baoquan He
2022-04-25  2:45     ` Baoquan He
2022-04-25  6:29     ` Leizhen
2022-04-25  6:29       ` Leizhen (ThunderTown)
2022-04-25  6:29       ` Leizhen (ThunderTown)

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=YnPdIvOktZBQYLjg@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=kexec@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.