Messages in this thread |  | | Date | Fri, 27 Jun 2025 14:18:21 +0200 | | Subject | Re: [PATCH v3 3/5] kdump, documentation: describe craskernel CMA reservation | | From | David Hildenbrand <> |
| |
On 27.06.25 14:16, David Hildenbrand wrote: > On 14.03.25 04:18, Baoquan He wrote: >> Hi Jiri, >> >> On 03/12/25 at 10:09pm, Jiri Bohac wrote: >> ...... >>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt >>> index fb8752b42ec8..895b974dc3bb 100644 >>> --- a/Documentation/admin-guide/kernel-parameters.txt >>> +++ b/Documentation/admin-guide/kernel-parameters.txt >>> @@ -987,6 +987,28 @@ >>> 0: to disable low allocation. >>> It will be ignored when crashkernel=X,high is not used >>> or memory reserved is below 4G. >>> + crashkernel=size[KMG],cma >>> + [KNL, X86] Reserve additional crash kernel memory from >>> + CMA. This reservation is usable by the first system's >>> + userspace memory and kernel movable allocations (memory >>> + balloon, zswap). Pages allocated from this memory range >>> + will not be included in the vmcore so this should not >>> + be used if dumping of userspace memory is intended and >>> + it has to be expected that some movable kernel pages >>> + may be missing from the dump. >> >> Since David and Don expressed concern about the missing kernel pages >> allocated from CMA area in v2, and you argued this is still useful for >> VM system, I would like to invite David to help evaluate the whole >> series if it's worth from the VM and MM point of view. > > Balloon pages will not be dumped either way (PageOffline), so that is > not a convern. > > Zsmalloc pages ... are probably fine right now. They should likely only > be storing compressed user data. (not sure if they also store some other > datastructures, I think no, but might be wrong) > > My comment was rather forward-looking: that CMA memory only contains > user space memory is already not the case (but the existing cases might > be okay). In the future, as we support other movable allocations (as > raised, leaf page tables at some point, and there were discussions about > movable slab pages, although that might be challenging) this can change > (unless we find ways of not placing these allocations on CMA memory). > > So as is, this should be fine, but it's certainly something to be aware > of in the future. >
BTW, I realize this was a late reply, and that the series already proceeded. Just stumbled over that un-replied mail an thought I'd clarify my point here.
-- Cheers,
David / dhildenb
|  |