On 2022/11/7 22:07, Catalin Marinas wrote: > On Mon, Jul 11, 2022 at 05:03:18PM +0800, Zhen Lei wrote: >> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c >> index 339ee84e5a61a0b..5390f361208ccf7 100644 >> --- a/arch/arm64/mm/init.c >> +++ b/arch/arm64/mm/init.c >> @@ -96,6 +96,14 @@ phys_addr_t __ro_after_init arm64_dma_phys_limit = PHYS_MASK + 1; >> #define CRASH_ADDR_LOW_MAX arm64_dma_phys_limit >> #define CRASH_ADDR_HIGH_MAX (PHYS_MASK + 1) >> >> +/* >> + * This is an empirical value in x86_64 and taken here directly. Please >> + * refer to the code comment in reserve_crashkernel_low() of x86_64 for more >> + * details. >> + */ >> +#define DEFAULT_CRASH_KERNEL_LOW_SIZE \ >> + max(swiotlb_size_or_default() + (8UL << 20), 256UL << 20) > > I agree with Will here, we need a better comment and we might as well > change the default value to something else until someone tells us that > the default is not large enough. The default swiotlb size is 64M, so we > need to cover that. The extra 8MB for any additional low allocations are > ok as well but the 256MB doesn't make much sense to me, or at least not > together with the rest. > > If the main kernel got a command line option for a larger swiotlb, does > the crash kernel boot with the same command line? If not, we can just go Sometimes the image is shared, but the command line is often different. The command line of the crash kernel is specified by kexec --append=. > for a fixed 128M value here, which is double the default swiotlb buffer. Sorry, I missed this e-mail. Yes, fixed 128M would be better. I haven't seen anyone adding "swiotlb=" to the crash kernel. And, if the default size isn't enough, he can use crashkernel=Y,low. > -- Regards, Zhen Lei
