[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <lofhq3bgtl2bcbrbkgctyyg2gl7ef2naqdrplyb37jyde2xoeh@twcwhwthnzxd>
Date: Thu, 21 Aug 2025 01:35:35 -0700
From: Breno Leitao <leitao@...ian.org>
To: Jiri Bohac <jbohac@...e.cz>
Cc: Baoquan He <bhe@...hat.com>, Vivek Goyal <vgoyal@...hat.com>,
Dave Young <dyoung@...hat.com>, kexec@...ts.infradead.org, akpm@...ux-foundation.org,
Philipp Rudo <prudo@...hat.com>, Donald Dutile <ddutile@...hat.com>,
Pingfan Liu <piliu@...hat.com>, Tao Liu <ltao@...hat.com>, linux-kernel@...r.kernel.org,
David Hildenbrand <dhildenb@...hat.com>, Michal Hocko <mhocko@...e.cz>
Subject: Re: [PATCH v5 0/5] kdump: crashkernel reservation from CMA
Hello Jiri,
On Wed, Aug 20, 2025 at 06:20:13PM +0200, Jiri Bohac wrote:
> On Wed, Aug 20, 2025 at 08:46:54AM -0700, Breno Leitao wrote:
> > First, thank you for making this change; it’s very helpful.
> > I haven’t come across anything regarding arm64 support. Is this on
> > anyone’s to-do list?
>
> Yes, I plan to implement this at least for ppc64, arm64 and s390x,
> hopefully in time for 6.18.
Thanks!
I have another question. I assume it’s not possible to allocate only the
CMA crashkernel area for the kdump kernel, since we need to keep the
loaded kernel in the crashkernel area while the system is running.
Therefore, specifying crashkernel=X (without ',cma') is necessary.
At the same time, since the crashdump environment will use CMA, the
crashkernel area itself doesn’t need to be very large, as the CMA space
will be allocated later.
With that in mind, how do I find what is the recommended size for the
crashkernel area, assuming the CMA area will be more than sufficient at
runtime?
Does it need ot be much higher than the size of kdump kernel and initrd?
Thanks
--breno
Powered by blists - more mailing lists