From: Michal Hocko <mhocko@suse.com>
To: Philipp Rudo <prudo@redhat.com>
Cc: Baoquan He <bhe@redhat.com>, Donald Dutile <ddutile@redhat.com>,
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: Fri, 1 Dec 2023 12:55:52 +0100 [thread overview]
Message-ID: <ZWnJyArAmFo_uYPA@tiehlicka> (raw)
In-Reply-To: <20231201123353.2b3db7fa@rotkaeppchen>
On Fri 01-12-23 12:33:53, Philipp Rudo wrote:
[...]
> And yes, those are all what-if concerns but unfortunately that is all
> we have right now.
Should theoretical concerns without an actual evidence (e.g. multiple
drivers known to be broken) become a roadblock for this otherwise useful
feature?
> Only alternative would be to run extended tests in
> the field. Which means this user facing change needs to be included.
> Which also means that we are stuck with it as once a user facing change
> is in it's extremely hard to get rid of it again...
I am not really sure I follow you here. Are you suggesting once
crashkernel=cma is added it would become a user api and therefore
impossible to get rid of?
--
Michal Hocko
SUSE Labs
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@suse.com>
To: Philipp Rudo <prudo@redhat.com>
Cc: Baoquan He <bhe@redhat.com>, Donald Dutile <ddutile@redhat.com>,
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: Fri, 1 Dec 2023 12:55:52 +0100 [thread overview]
Message-ID: <ZWnJyArAmFo_uYPA@tiehlicka> (raw)
In-Reply-To: <20231201123353.2b3db7fa@rotkaeppchen>
On Fri 01-12-23 12:33:53, Philipp Rudo wrote:
[...]
> And yes, those are all what-if concerns but unfortunately that is all
> we have right now.
Should theoretical concerns without an actual evidence (e.g. multiple
drivers known to be broken) become a roadblock for this otherwise useful
feature?
> Only alternative would be to run extended tests in
> the field. Which means this user facing change needs to be included.
> Which also means that we are stuck with it as once a user facing change
> is in it's extremely hard to get rid of it again...
I am not really sure I follow you here. Are you suggesting once
crashkernel=cma is added it would become a user api and therefore
impossible to get rid of?
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2023-12-01 11:56 UTC|newest]
Thread overview: 96+ 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:54 ` Jiri Bohac
2023-11-24 19:57 ` [PATCH 1/4] kdump: add crashkernel cma suffix Jiri Bohac
2023-11-24 19:57 ` Jiri Bohac
2023-11-25 7:24 ` kernel test robot
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 ` Jiri Bohac
2023-11-24 19:58 ` [PATCH 3/4] kdump, x86: implement crashkernel CMA reservation Jiri Bohac
2023-11-24 19:58 ` Jiri Bohac
2023-11-24 19:58 ` [PATCH 4/4] kdump, documentation: describe craskernel " Jiri Bohac
2023-11-24 19:58 ` Jiri Bohac
2023-11-25 1:51 ` [PATCH 0/4] kdump: crashkernel reservation from CMA Tao Liu
2023-11-25 1:51 ` Tao Liu
2023-11-25 21:22 ` Jiri Bohac
2023-11-25 21:22 ` Jiri Bohac
2023-11-28 1:12 ` Tao Liu
2023-11-28 1:12 ` Tao Liu
2023-11-28 2:11 ` Baoquan He
2023-11-28 2:11 ` Baoquan He
2023-11-28 9:08 ` Michal Hocko
2023-11-28 9:08 ` Michal Hocko
2023-11-29 7:57 ` Baoquan He
2023-11-29 7:57 ` Baoquan He
2023-11-29 9:25 ` Michal Hocko
2023-11-29 9:25 ` Michal Hocko
2023-11-30 2:42 ` Baoquan He
2023-11-30 2:42 ` Baoquan He
2023-11-29 10:51 ` Jiri Bohac
2023-11-29 10:51 ` Jiri Bohac
2023-11-30 4:01 ` Baoquan He
2023-11-30 4:01 ` Baoquan He
2023-12-01 12:35 ` Jiri Bohac
2023-12-01 12:35 ` Jiri Bohac
2023-11-29 8:10 ` Baoquan He
2023-11-29 8:10 ` Baoquan He
2023-11-29 15:03 ` Donald Dutile
2023-11-29 15:03 ` Donald Dutile
2023-11-30 3:00 ` Baoquan He
2023-11-30 3:00 ` Baoquan He
2023-11-30 10:16 ` Michal Hocko
2023-11-30 10:16 ` Michal Hocko
2023-11-30 12:04 ` Baoquan He
2023-11-30 12:04 ` Baoquan He
2023-11-30 12:31 ` Baoquan He
2023-11-30 12:31 ` Baoquan He
2023-11-30 13:41 ` Michal Hocko
2023-11-30 13:41 ` Michal Hocko
2023-12-01 11:33 ` Philipp Rudo
2023-12-01 11:33 ` Philipp Rudo
2023-12-01 11:55 ` Michal Hocko [this message]
2023-12-01 11:55 ` Michal Hocko
2023-12-01 15:51 ` Philipp Rudo
2023-12-01 15:51 ` Philipp Rudo
2023-12-01 16:59 ` Michal Hocko
2023-12-01 16:59 ` Michal Hocko
2023-12-06 11:08 ` Philipp Rudo
2023-12-06 11:08 ` Philipp Rudo
2023-12-06 11:23 ` David Hildenbrand
2023-12-06 11:23 ` David Hildenbrand
2023-12-06 13:49 ` Michal Hocko
2023-12-06 13:49 ` Michal Hocko
2023-12-06 15:19 ` Michal Hocko
2023-12-06 15:19 ` Michal Hocko
2023-12-07 4:23 ` Baoquan He
2023-12-07 4:23 ` Baoquan He
2023-12-07 8:55 ` Michal Hocko
2023-12-07 8:55 ` Michal Hocko
2023-12-07 11:13 ` Philipp Rudo
2023-12-07 11:13 ` Philipp Rudo
2023-12-07 11:52 ` Michal Hocko
2023-12-07 11:52 ` Michal Hocko
2023-12-08 1:55 ` Baoquan He
2023-12-08 1:55 ` Baoquan He
2023-12-08 10:04 ` Michal Hocko
2023-12-08 10:04 ` Michal Hocko
2023-12-08 2:10 ` Baoquan He
2023-12-08 2:10 ` Baoquan He
2023-12-07 11:13 ` Philipp Rudo
2023-12-07 11:13 ` Philipp Rudo
2023-11-30 13:29 ` Michal Hocko
2023-11-30 13:29 ` Michal Hocko
2023-11-30 13:33 ` Pingfan Liu
2023-11-30 13:33 ` Pingfan Liu
2023-11-30 13:43 ` Michal Hocko
2023-11-30 13:43 ` Michal Hocko
2023-12-01 0:54 ` Pingfan Liu
2023-12-01 0:54 ` Pingfan Liu
2023-12-01 10:37 ` Michal Hocko
2023-12-01 10:37 ` Michal Hocko
2023-11-28 2:07 ` Pingfan Liu
2023-11-28 2:07 ` Pingfan Liu
2023-11-28 8:58 ` Michal Hocko
2023-11-28 8:58 ` Michal Hocko
2023-12-01 11:34 ` Philipp Rudo
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=ZWnJyArAmFo_uYPA@tiehlicka \
--to=mhocko@suse.com \
--cc=bhe@redhat.com \
--cc=ddutile@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=prudo@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 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.