All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <baoquan.he@linux.dev>
To: Wandun Chen <chenwandun1@gmail.com>
Cc: catalin.marinas@arm.com, will@kernel.org, chenhuacai@kernel.org,
	pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu,
	tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
	dave.hansen@linux.intel.com, x86@kernel.org, robh@kernel.org,
	saravanak@kernel.org, akpm@linux-foundation.org, rppt@kernel.org,
	pasha.tatashin@soleen.com, pratyush@kernel.org,
	m.szyprowski@samsung.com, mark.rutland@arm.com,
	kernel@xen0n.name, alex@ghiti.fr, hpa@zytor.com,
	ruirui.yang@linux.dev, robin.murphy@arm.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
	kexec@lists.infradead.org, linux-mm@kvack.org,
	iommu@lists.linux.dev
Subject: Re: [PATCH v6 00/10] kdump: reduce vmcore size and capture time
Date: Fri, 18 Sep 2026 16:17:32 +0800	[thread overview]
Message-ID: <aqzznOgILX2pZg7b@fedora> (raw)
In-Reply-To: <20260902073116.802752-1-chenwandun1@gmail.com>

On 09/02/26 at 03:31pm, Wandun Chen wrote:
> From: Wandun Chen <chenwandun@lixiang.com>
> 
...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()?

IMHO, withdrawing the claim can fix the nit concern. If I am wrong,
please help point it out to let me learn more.

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...

WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <baoquan.he@linux.dev>
To: Wandun Chen <chenwandun1@gmail.com>
Cc: catalin.marinas@arm.com, will@kernel.org, chenhuacai@kernel.org,
	pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu,
	tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
	dave.hansen@linux.intel.com, x86@kernel.org, robh@kernel.org,
	saravanak@kernel.org, akpm@linux-foundation.org, rppt@kernel.org,
	pasha.tatashin@soleen.com, pratyush@kernel.org,
	m.szyprowski@samsung.com, mark.rutland@arm.com,
	kernel@xen0n.name, alex@ghiti.fr, hpa@zytor.com,
	ruirui.yang@linux.dev, robin.murphy@arm.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
	kexec@lists.infradead.org, linux-mm@kvack.org,
	iommu@lists.linux.dev
Subject: Re: [PATCH v6 00/10] kdump: reduce vmcore size and capture time
Date: Fri, 18 Sep 2026 16:17:32 +0800	[thread overview]
Message-ID: <aqzznOgILX2pZg7b@fedora> (raw)
In-Reply-To: <20260902073116.802752-1-chenwandun1@gmail.com>

On 09/02/26 at 03:31pm, Wandun Chen wrote:
> From: Wandun Chen <chenwandun@lixiang.com>
> 
...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()?

IMHO, withdrawing the claim can fix the nit concern. If I am wrong,
please help point it out to let me learn more.

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...

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  parent reply	other threads:[~2026-09-18  8:17 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02  7:31 [PATCH v6 00/10] kdump: reduce vmcore size and capture time Wandun Chen
2026-09-02  7:31 ` Wandun Chen
2026-09-02  7:31 ` [PATCH v6 01/10] mm: memblock: add missing HugeTLB flag name Wandun Chen
2026-09-02  7:31   ` Wandun Chen
2026-09-02  7:43   ` sashiko-bot
2026-09-14  5:20   ` Mike Rapoport
2026-09-14  5:20     ` Mike Rapoport
2026-09-15 12:49     ` Wandun
2026-09-15 12:49       ` Wandun
2026-09-02  7:31 ` [PATCH v6 02/10] riscv: build crash_mem ranges from memblock instead of resource tree Wandun Chen
2026-09-02  7:31   ` Wandun Chen
2026-09-21  5:48   ` Baoquan He
2026-09-21  5:48     ` Baoquan He
2026-09-02  7:31 ` [PATCH v6 03/10] crash_core: fold duplicated memblock arch hooks into the weak default Wandun Chen
2026-09-02  7:31   ` Wandun Chen
2026-09-18  7:30   ` Baoquan He
2026-09-18  7:30     ` Baoquan He
2026-09-18  8:45     ` Wandun
2026-09-18  8:45       ` Wandun
2026-09-18  8:48       ` Baoquan He
2026-09-18  8:48         ` Baoquan He
2026-09-02  7:31 ` [PATCH v6 04/10] crash_core: serialize crash header preparation against hotplug Wandun Chen
2026-09-02  7:31   ` Wandun Chen
2026-09-18  7:54   ` Baoquan He
2026-09-18  7:54     ` Baoquan He
2026-09-02  7:31 ` [PATCH v6 05/10] crash_core: replace for_each_mem_range() with for_each_mem_region() Wandun Chen
2026-09-02  7:31   ` Wandun Chen
2026-09-18  8:04   ` Baoquan He
2026-09-18  8:04     ` Baoquan He
2026-09-02  7:31 ` [PATCH v6 06/10] memblock: introduce MEMBLOCK_NODUMP flag Wandun Chen
2026-09-02  7:31   ` Wandun Chen
2026-09-18  7:00   ` Mike Rapoport
2026-09-18  7:00     ` Mike Rapoport
2026-09-18  8:08   ` Baoquan He
2026-09-18  8:08     ` Baoquan He
2026-09-18  8:22     ` Wandun
2026-09-18  8:22       ` Wandun
2026-09-19  7:11     ` Mike Rapoport
2026-09-19  7:11       ` Mike Rapoport
2026-09-20  3:33       ` Baoquan He
2026-09-20  3:33         ` Baoquan He
2026-09-20  8:00         ` Wandun
2026-09-20  8:00           ` Wandun
2026-09-21  5:52           ` Baoquan He
2026-09-21  5:52             ` Baoquan He
2026-09-02  7:31 ` [PATCH v6 07/10] of: reserved_mem: add dumpable flag to opt-in vmcore Wandun Chen
2026-09-02  7:31   ` Wandun Chen
2026-09-17 21:56   ` Rob Herring (Arm)
2026-09-17 21:56     ` Rob Herring (Arm)
2026-09-02  7:31 ` [PATCH v6 08/10] of: reserved_mem: mark /reserved-memory entries with MEMBLOCK_NODUMP Wandun Chen
2026-09-02  7:31   ` Wandun Chen
2026-09-03  7:32   ` Marek Szyprowski
2026-09-03  7:32     ` Marek Szyprowski
2026-09-17 21:56   ` Rob Herring (Arm)
2026-09-17 21:56     ` Rob Herring (Arm)
2026-09-02  7:31 ` [PATCH v6 09/10] of: reserved_mem: mark /memreserve/ entries as MEMBLOCK_NODUMP Wandun Chen
2026-09-02  7:31   ` Wandun Chen
2026-09-02  9:02   ` sashiko-bot
2026-09-17 22:07     ` Rob Herring
2026-09-18  6:20       ` Wandun
2026-09-03  7:32   ` Marek Szyprowski
2026-09-03  7:32     ` Marek Szyprowski
2026-09-02  7:31 ` [PATCH v6 10/10] crash_core: skip MEMBLOCK_NODUMP regions when building vmcore ELF header Wandun Chen
2026-09-02  7:31   ` Wandun Chen
2026-09-18  8:09   ` Baoquan He
2026-09-18  8:09     ` Baoquan He
2026-09-02  8:53 ` [PATCH v6 00/10] kdump: reduce vmcore size and capture time Baoquan He
2026-09-02  8:53   ` Baoquan He
2026-09-03  7:05   ` Wandun
2026-09-03  7:05     ` Wandun
2026-09-03  7:31     ` Baoquan He
2026-09-03  7:31       ` Baoquan He
2026-09-03  7:43       ` Wandun
2026-09-03  7:43         ` Wandun
2026-09-03  9:38         ` Baoquan He
2026-09-03  9:38           ` Baoquan He
2026-09-04 11:08           ` Chen Wandun
2026-09-04 11:08             ` Chen Wandun
2026-09-15 13:01 ` Wandun
2026-09-15 13:01   ` Wandun
2026-09-18  7:03   ` Mike Rapoport
2026-09-18  7:03     ` Mike Rapoport
2026-09-18  7:31     ` Baoquan He
2026-09-18  7:31       ` Baoquan He
2026-09-18  8:17 ` Baoquan He [this message]
2026-09-18  8:17   ` Baoquan He
2026-09-18 10:53   ` Wandun
2026-09-18 10:53     ` Wandun

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=aqzznOgILX2pZg7b@fedora \
    --to=baoquan.he@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=chenhuacai@kernel.org \
    --cc=chenwandun1@gmail.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux.dev \
    --cc=kernel@xen0n.name \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=loongarch@lists.linux.dev \
    --cc=m.szyprowski@samsung.com \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=palmer@dabbelt.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=pjw@kernel.org \
    --cc=pratyush@kernel.org \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=rppt@kernel.org \
    --cc=ruirui.yang@linux.dev \
    --cc=saravanak@kernel.org \
    --cc=tglx@kernel.org \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.