Messages in this thread | | | Date | Tue, 3 May 2022 19:20:18 +0100 | From | Catalin Marinas <> | Subject | Re: [PATCH v3 0/3] arm64: mm: Do not defer reserve_crashkernel() |
| |
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
| |