Re: [PATCH v6 00/10] kdump: reduce vmcore size and capture time
Wandun <[email protected]>
| Newsgroups | org.kernel.vger.linux-kernel,dev.linux.lists.iommu,dev.linux.lists.loongarch,org.infradead.lists.kexec,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-riscv,org.kernel.vger.linux-devicetree,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On 9/18/26 16:17, Baoquan He wrote: > On 09/02/26 at 03:31pm, Wandun Chen wrote: >> From: Wandun Chen <[email protected]> >> > ...snip... >> ACPI systems already filter reserved memory out of the vmcore through >> their existing path; only DT-based systems currently fail to filter these >> regions, which is what this series addresses. The flag lives in memblock >> itself rather than in a DT-only structure, so the mechanism is generic and > ~~~ > The patchset itself looks goot to me, while I am concerned if it's > really generic. I raised that in sub-thread talking with Wandun. Imagine > I tried to exclude many driver regions and split memblock regions into > hundreds, cma could yell out: cma_declare_contiguous_multi()? Are you concerned that setting the MEMBLOCK_NODUMP flag could split a memblock region into many smaller regions, which might then prevent cma_declare_contiguous_multi() from satisfying a multi-range allocation? If so, IICU I don’t think that applies here. MEMBLOCK_NODUMP is currently only set on memory that has already been reserved. These regions are excluded when iterating over free memory, so marking them NODUMP does not increase the number of free regions seen by CMA. Before marking NODUMP: memblock.memory: [ free ] [ reserved ] [ free ] memblock.reserved: [ reserved ] Now, for memblock.memory, it is one region that contains free and reserved memory. After marking the reserved region NODUMP: memblock.memory: [ free ] [ NODUMP ] [ free ] memblock.reserved: [ reserved ] for memblock.memory, it splits into 3 regions, 2 free regions, 1 nodump region. Although the memblock.memory array may be split internally, it does not create additional free ranges for cma_declare_contiguous_multi() to process. > > IMHO, withdrawing the claim can fix the nit concern. If I am wrong, > please help point it out to let me learn more. I will revise this description to avoid any misunderstanding. Best regards, Wandun > > Thanks > Baoquan > >> both ACPI and DT systems can benefit from it (suggested by Rob, thanks) [1]. >> >> Since the reserved memory regions are filtered out, the vmcore is >> smaller in size and faster to produce. >> > ...snip...