[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZWnJyArAmFo_uYPA@tiehlicka>
Date: Fri, 1 Dec 2023 12:55:52 +0100
From: Michal Hocko <mhocko@...e.com>
To: Philipp Rudo <prudo@...hat.com>
Cc: Baoquan He <bhe@...hat.com>, Donald Dutile <ddutile@...hat.com>,
Jiri Bohac <jbohac@...e.cz>, Pingfan Liu <piliu@...hat.com>,
Tao Liu <ltao@...hat.com>, Vivek Goyal <vgoyal@...hat.com>,
Dave Young <dyoung@...hat.com>, kexec@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] kdump: crashkernel reservation from CMA
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
Powered by blists - more mailing lists