From: Baoquan He <bhe@redhat.com>
To: Zhongkun He <hezhongkun.hzk@bytedance.com>
Cc: Alexander Graf <graf@amazon.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
nh-open-source@amazon.com
Subject: Re: [External] [PATCH v3] kexec: Enable CMA based contiguous allocation
Date: Wed, 21 May 2025 18:30:14 +0800 [thread overview]
Message-ID: <aC2rNv49pzy1Wh3D@MiWiFi-R3L-srv> (raw)
In-Reply-To: <CACSyD1OU1zjvc2YdQpi-F_qZ0EWyb6jLNODJkRDPQa6m1eObJg@mail.gmail.com>
On 05/21/25 at 03:47pm, Zhongkun He wrote:
> On Wed, May 14, 2025 at 2:40 AM Alexander Graf <graf@amazon.com> wrote:
......
> > /**
> > * kexec_locate_mem_hole - find free memory for the purgatory or the next kernel
> > * @kbuf: Parameters for the memory search.
> > @@ -648,6 +684,13 @@ int kexec_locate_mem_hole(struct kexec_buf *kbuf)
> > if (kbuf->mem != KEXEC_BUF_MEM_UNKNOWN)
> > return 0;
> >
> > + /*
> > + * Try to find a free physically contiguous block of memory first. With that, we
> > + * can avoid any copying at kexec time.
> > + */
> > + if (!kexec_alloc_contig(kbuf))
> > + return 0;
>
> IIUC, The kexec_locate_mem_hole() function is also used in
> the KEXEC_TYPE_CRASH kimage, but kexec_alloc_contig() does not skip it.
> This can cause kdump to fail and lead to CMA memory leakage.
That is true and good catch, and fix is needed to skip cma alloc for
kdump.
>
> So I ran some tests, as listed below:
> The CMA memory decreases with each execution of the kdump-config
> reload operation.
>
> /home/hezhongkun.hzk# kdump-config reload
> unloaded kdump kernel.
> Creating symlink /var/lib/kdump/vmlinuz.
> Creating symlink /var/lib/kdump/initrd.img.
> kexec_file_load failed: Cannot assign requested address
> failed to load kdump kernel ... failed!
>
> [ 1387.536346] kexec_file: allocated 1817 DMA pages at 0x11b16e
> [ 1399.147677] kexec_file: allocated 113 DMA pages at 0x119087
> [ 1399.148915] kexec_file: allocated 5 DMA pages at 0x1140f8
> [ 1399.150266] kexec_file: allocated 2 DMA pages at 0x1118fd
> [ 1399.151474] kexec_file: allocated 8302 DMA pages at 0x11b900
>
> /home/hezhongkun.hzk# cat /proc/meminfo | grep Cma
> CmaTotal: 1048576 kB
> CmaFree: 679972 kB
> /home/hezhongkun.hzk# cat /proc/meminfo | grep Cma
> CmaTotal: 1048576 kB
> CmaFree: 639016 kB
> /home/hezhongkun.hzk# cat /proc/meminfo | grep Cma
> CmaTotal: 1048576 kB
> CmaFree: 557104 kB
>
> cat /proc/meminfo | grep Cma
> CmaTotal: 1048576 kB
> CmaFree: 557104 kB
>
> > +
> > if (!IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK))
> > ret = kexec_walk_resources(kbuf, locate_mem_hole_callback);
> > else
> > @@ -693,6 +736,7 @@ int kexec_add_buffer(struct kexec_buf *kbuf)
> > /* Ensure minimum alignment needed for segments. */
> > kbuf->memsz = ALIGN(kbuf->memsz, PAGE_SIZE);
> > kbuf->buf_align = max(kbuf->buf_align, PAGE_SIZE);
> > + kbuf->cma = NULL;
> >
> > /* Walk the RAM ranges and allocate a suitable range for the buffer */
> > ret = arch_kexec_locate_mem_hole(kbuf);
> > @@ -705,6 +749,7 @@ int kexec_add_buffer(struct kexec_buf *kbuf)
> > ksegment->bufsz = kbuf->bufsz;
> > ksegment->mem = kbuf->mem;
> > ksegment->memsz = kbuf->memsz;
> > + kbuf->image->segment_cma[kbuf->image->nr_segments] = kbuf->cma;
> > kbuf->image->nr_segments++;
> > return 0;
> > }
> > diff --git a/kernel/kexec_internal.h b/kernel/kexec_internal.h
> > index d35d9792402d..29e6cebe0c43 100644
> > --- a/kernel/kexec_internal.h
> > +++ b/kernel/kexec_internal.h
> > @@ -10,7 +10,7 @@ struct kimage *do_kimage_alloc_init(void);
> > int sanity_check_segment_list(struct kimage *image);
> > void kimage_free_page_list(struct list_head *list);
> > void kimage_free(struct kimage *image);
> > -int kimage_load_segment(struct kimage *image, struct kexec_segment *segment);
> > +int kimage_load_segment(struct kimage *image, int idx);
> > void kimage_terminate(struct kimage *image);
> > int kimage_is_destination_range(struct kimage *image,
> > unsigned long start, unsigned long end);
> > --
> > 2.34.1
> >
> >
> >
> >
> > Amazon Web Services Development Center Germany GmbH
> > Tamara-Danz-Str. 13
> > 10243 Berlin
> > Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> > Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
> > Sitz: Berlin
> > Ust-ID: DE 365 538 597
> >
> >
>
next prev parent reply other threads:[~2025-05-21 10:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-13 18:02 [PATCH v3] kexec: Enable CMA based contiguous allocation Alexander Graf
2025-05-21 7:47 ` [External] " Zhongkun He
2025-05-21 10:30 ` Baoquan He [this message]
2025-05-21 15:30 ` Alexander Graf
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=aC2rNv49pzy1Wh3D@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=graf@amazon.com \
--cc=hezhongkun.hzk@bytedance.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nh-open-source@amazon.com \
--cc=pasha.tatashin@soleen.com \
/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