public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Philipp Rudo <prudo@redhat.com>
To: Jiri Bohac <jbohac@suse.cz>
Cc: Baoquan He <bhe@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
	Dave Young <dyoung@redhat.com>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	mhocko@suse.cz
Subject: Re: [PATCH 0/4] kdump: crashkernel reservation from CMA
Date: Fri, 1 Dec 2023 12:34:04 +0100	[thread overview]
Message-ID: <20231201123404.49a46a64@rotkaeppchen> (raw)
In-Reply-To: <ZWD_fAPqEWkFlEkM@dwarf.suse.cz>

Hi Jiri,

I'd really love to see something like this to work. Although I also
share the concerns about shitty device drivers corrupting the CMA.
Please see my other mail for that.

Anyway, one more comment below.

On Fri, 24 Nov 2023 20:54:36 +0100
Jiri Bohac <jbohac@suse.cz> wrote:

[...]
 
> Now, specifying
> 	crashkernel=100M craskhernel=1G,cma
> on the command line will make a standard crashkernel reservation
> of 100M, where kexec will load the kernel and initrd.
> 
> An additional 1G will be reserved from CMA, still usable by the
> production system. The crash kernel will have 1.1G memory
> available. The 100M can be reliably predicted based on the size
> of the kernel and initrd.

I doubt that the fixed part can be predicted "reliably". For sure it
will be more reliable than today but IMHO we will still be stuck with
some guessing. Otherwise it would mean that you already know during
boot which initrd the user space will be loading later on. Which IMHO is
impossible as the initrd can always be rebuild with a larger size.
Furthermore, I'd be careful when you are dealing with compressed kernel
images. As I'm not sure how the different decompressor phases would
handle scenarios where the (fixed) crashkernel memory is large enough
to hold the compressed kernel (+initrd) but not the decompressed one.

One more thing, I'm not sure I like that you need to reserve two
separate memory regions. Personally I would prefer it if you could
reserve one large region for the crashkernel but allow parts of it to
be reused via CMA. Otherwise I'm afraid there will be people who only
have one ,cma entry on the command line and cannot figure out why they
cannot load the crash kernel.

Thanks
Philipp
 
> When no crashkernel=size,cma is specified, everything works as
> before.
> 


      parent reply	other threads:[~2023-12-01 11:34 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
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 [this message]

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=20231201123404.49a46a64@rotkaeppchen \
    --to=prudo@redhat.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=mhocko@suse.cz \
    --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