From: Michal Hocko <mhocko@suse.com>
To: Baoquan He <bhe@redhat.com>
Cc: Jiri Bohac <jbohac@suse.cz>, Pingfan Liu <piliu@redhat.com>,
Tao Liu <ltao@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
Dave Young <dyoung@redhat.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] kdump: crashkernel reservation from CMA
Date: Tue, 28 Nov 2023 10:08:21 +0100 [thread overview]
Message-ID: <ZWWuBSiZZdF2W12j@tiehlicka> (raw)
In-Reply-To: <ZWVMUxmi66xLZPsr@MiWiFi-R3L-srv>
On Tue 28-11-23 10:11:31, Baoquan He wrote:
> On 11/28/23 at 09:12am, Tao Liu wrote:
[...]
> Thanks for the effort to bring this up, Jiri.
>
> I am wondering how you will use this crashkernel=,cma parameter. I mean
> the scenario of crashkernel=,cma. Asking this because I don't know how
> SUSE deploy kdump in SUSE distros. In SUSE distros, kdump kernel's
> driver will be filter out? If latter case, It's possibly having the
> on-flight DMA issue, e.g NIC has DMA buffer in the CMA area, but not
> reset during kdump bootup because the NIC driver is not loaded in to
> initialize. Not sure if this is 100%, possible in theory?
NIC drivers do not allocation from movable zones (that includes CMA
zone). In fact kernel doesn't use GFP_MOVABLE for non-user requests.
RDMA drivers might and do transfer from user backed memory but for that
purpose they should be pinning memory (have a look at
__gup_longterm_locked and its callers) and that will migrate away from
the any zone.
[...]
> The crashkernel=,cma requires no userspace data dumping, from our
> support engineers' feedback, customer never express they don't need to
> dump user space data. Assume a server with huge databse deployed, and
> the database often collapsed recently and database provider claimed that
> it's not database's fault, OS need prove their innocence. What will you
> do?
Don't use CMA backed crash memory then? This is an optional feature.
> So this looks like a nice to have to me. At least in fedora/rhel's
> usage, we may only back port this patch, and add one sentence in our
> user guide saying "there's a crashkernel=,cma added, can be used with
> crashkernel= to save memory. Please feel free to try if you like".
> Unless SUSE or other distros decides to use it as default config or
> something like that. Please correct me if I missed anything or took
> anything wrong.
Jiri will know better than me but for us a proper crash memory
configuration has become a real nut. You do not want to reserve too much
because it is effectively cutting of the usable memory and we regularly
hit into "not enough memory" if we tried to be savvy. The more tight you
try to configure the easier to fail that is. Even worse any in kernel
memory consumer can increase its memory demand and get the overall
consumption off the cliff. So this is not an easy to maintain solution.
CMA backed crash memory can be much more generous while still usable.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2023-11-28 9:08 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-24 19:54 [PATCH 0/4] kdump: crashkernel reservation from CMA Jiri Bohac
2023-11-24 19:57 ` [PATCH 1/4] kdump: add crashkernel cma suffix Jiri Bohac
2023-11-25 7:24 ` kernel test robot
2023-11-24 19:58 ` [PATCH 2/4] kdump: implement reserve_crashkernel_cma Jiri Bohac
2023-11-24 19:58 ` [PATCH 3/4] kdump, x86: implement crashkernel CMA reservation Jiri Bohac
2023-11-24 19:58 ` [PATCH 4/4] kdump, documentation: describe craskernel " Jiri Bohac
2023-11-25 1:51 ` [PATCH 0/4] kdump: crashkernel reservation from CMA Tao Liu
2023-11-25 21:22 ` Jiri Bohac
2023-11-28 1:12 ` Tao Liu
2023-11-28 2:11 ` Baoquan He
2023-11-28 9:08 ` Michal Hocko [this message]
2023-11-29 7:57 ` Baoquan He
2023-11-29 9:25 ` Michal Hocko
2023-11-30 2:42 ` Baoquan He
2023-11-29 10:51 ` Jiri Bohac
2023-11-30 4:01 ` Baoquan He
2023-12-01 12:35 ` Jiri Bohac
2023-11-29 8:10 ` Baoquan He
2023-11-29 15:03 ` Donald Dutile
2023-11-30 3:00 ` Baoquan He
2023-11-30 10:16 ` Michal Hocko
2023-11-30 12:04 ` Baoquan He
2023-11-30 12:31 ` Baoquan He
2023-11-30 13:41 ` Michal Hocko
2023-12-01 11:33 ` Philipp Rudo
2023-12-01 11:55 ` Michal Hocko
2023-12-01 15:51 ` Philipp Rudo
2023-12-01 16:59 ` Michal Hocko
2023-12-06 11:08 ` Philipp Rudo
2023-12-06 11:23 ` David Hildenbrand
2023-12-06 13:49 ` Michal Hocko
2023-12-06 15:19 ` Michal Hocko
2023-12-07 4:23 ` Baoquan He
2023-12-07 8:55 ` Michal Hocko
2023-12-07 11:13 ` Philipp Rudo
2023-12-07 11:52 ` Michal Hocko
2023-12-08 1:55 ` Baoquan He
2023-12-08 10:04 ` Michal Hocko
2023-12-08 2:10 ` Baoquan He
2023-12-07 11:13 ` Philipp Rudo
2023-11-30 13:29 ` Michal Hocko
2023-11-30 13:33 ` Pingfan Liu
2023-11-30 13:43 ` Michal Hocko
2023-12-01 0:54 ` Pingfan Liu
2023-12-01 10:37 ` Michal Hocko
2023-11-28 2:07 ` Pingfan Liu
2023-11-28 8:58 ` Michal Hocko
2023-12-01 11:34 ` Philipp Rudo
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=ZWWuBSiZZdF2W12j@tiehlicka \
--to=mhocko@suse.com \
--cc=bhe@redhat.com \
--cc=dyoung@redhat.com \
--cc=jbohac@suse.cz \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ltao@redhat.com \
--cc=piliu@redhat.com \
--cc=vgoyal@redhat.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