From: Catalin Marinas <catalin.marinas@arm.com>
To: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: will@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, vijayb@linux.microsoft.com,
f.fainelli@gmail.com
Subject: Re: [PATCH v3 0/3] arm64: mm: Do not defer reserve_crashkernel()
Date: Tue, 3 May 2022 19:20:18 +0100 [thread overview]
Message-ID: <YnFyYm93IVNlCQ4c@arm.com> (raw)
In-Reply-To: <20220411092455.1461-1-wangkefeng.wang@huawei.com>
On Mon, Apr 11, 2022 at 05:24:52PM +0800, Kefeng Wang wrote:
> Commit 031495635b46 ("arm64: Do not defer reserve_crashkernel() for
> platforms with no DMA memory zones"), this lets the kernel benifit
> due to BLOCK_MAPPINGS, we could do more if ZONE_DMA and ZONE_DMA32
> enabled.
>
> 1) Don't defer reserve_crashkernel() if only ZONE_DMA32
> 2) Don't defer reserve_crashkernel() if ZONE_DMA with dma_force_32bit
> kernel parameter(newly added)
I'm not really keen on a new kernel parameter for this. But even with
such parameter, there is another series that allows crashkernel
reservations above ZONE_DMA32, so that would also need
NO_BLOCK_MAPPINGS, at least initially. I think there was a proposal to
do the high reservation first and only defer the low one in ZONE_DMA but
suggested we get the reservations sorted first and look at optimisations
later.
If hardware is so bad with page mappings, I think we need to look at
different ways to enable the block mappings, e.g. some safe break
before make change of the mappings or maybe switching to another TTBR1
during boot.
Does FEAT_BBM level 2 allow us to change the block size without a break
before make? I think that can still trigger a TLB conflict abort, maybe
we can trap it and invalidate the TLBs (the conflict should be on the
linear map not where the kernel image is mapped).
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-05-03 18:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-11 9:24 [PATCH v3 0/3] arm64: mm: Do not defer reserve_crashkernel() Kefeng Wang
2022-04-11 9:24 ` [PATCH v3 1/3] arm64: mm: Do not defer reserve_crashkernel() if only ZONE_DMA32 Kefeng Wang
2022-04-11 9:24 ` [PATCH v3 2/3] arm64: mm: Don't defer reserve_crashkernel() with dma_force_32bit Kefeng Wang
2022-04-11 9:24 ` [PATCH v3 3/3] arm64: mm: Cleanup useless parameters in zone_sizes_init() Kefeng Wang
2022-04-27 12:41 ` [PATCH v3 0/3] arm64: mm: Do not defer reserve_crashkernel() Kefeng Wang
2022-05-03 18:20 ` Catalin Marinas [this message]
2022-05-05 3:04 ` Kefeng Wang
2022-05-05 8:26 ` (subset) " Catalin Marinas
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=YnFyYm93IVNlCQ4c@arm.com \
--to=catalin.marinas@arm.com \
--cc=f.fainelli@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vijayb@linux.microsoft.com \
--cc=wangkefeng.wang@huawei.com \
--cc=will@kernel.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 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).