Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
Date:   Fri, 1 Dec 2023 17:59:02 +0100
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
Message-ID: <ZWoQ1k2AikSiMjys@tiehlicka>
References: <ZWbyDx3TJ7zo3jCw@MiWiFi-R3L-srv>
 <91a31ce5-63d1-7470-18f7-92b039fda8e6@redhat.com>
 <ZWf64BowWrYqA2Rf@MiWiFi-R3L-srv>
 <ZWhg_b3O6piZtkQ-@tiehlicka>
 <ZWh6ax8YmkhxAzIf@MiWiFi-R3L-srv>
 <ZWiAsJlLookvCI+h@MiWiFi-R3L-srv>
 <ZWiQ-II9CvGv8EWK@tiehlicka>
 <20231201123353.2b3db7fa@rotkaeppchen>
 <ZWnJyArAmFo_uYPA@tiehlicka>
 <20231201165113.43211a48@rotkaeppchen>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231201165113.43211a48@rotkaeppchen>
Precedence: bulk

On Fri 01-12-23 16:51:13, Philipp Rudo wrote:
> On Fri, 1 Dec 2023 12:55:52 +0100
> Michal Hocko <mhocko@suse.com> wrote:
> 
> > 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? 
> 
> Those concerns aren't just theoretical. They are experiences we have
> from a related feature that suffers exactly the same problem regularly
> which wouldn't exist if everybody would simply work "properly".

What is the related feature?
 
> And yes, even purely theoretical concerns can become a roadblock for a
> feature when the cost of those theoretical concerns exceed the benefit
> of the feature. The thing is that bugs will be reported against kexec.
> So _we_ need to figure out which of the shitty drivers caused the
> problem. That puts additional burden on _us_. What we are trying to
> evaluate at the moment is if the benefit outweighs the extra burden
> with the information we have at the moment.

I do understand your concerns! But I am pretty sure you do realize that
it is really hard to argue theoreticals.  Let me restate what I consider
facts. Hopefully we can agree on these points
	- the CMA region can be used by user space memory which is a
	  great advantage because the memory is not wasted and our
	  experience has shown that users do care about this a lot. We
	  _know_ that pressure on making those reservations smaller
	  results in a less reliable crashdump and more resources spent
	  on tuning and testing (especially after major upgrades).  A
	  larger reservation which is not completely wasted for the
	  normal runtime is addressing that concern.
	- There is no other known mechanism to achieve the reusability
	  of the crash kernel memory to stop the wastage without much
	  more intrusive code/api impact (e.g. a separate zone or
	  dedicated interface to prevent any hazardous usage like RDMA).
	- implementation wise the patch has a very small footprint. It
	  is using an existing infrastructure (CMA) and it adds a
	  minimal hooking into crashkernel configuration.
	- The only identified risk so far is RDMA acting on this memory
	  without using proper pinning interface. If it helps to have a
	  statement from RDMA maintainers/developers then we can pull
	  them in for a further discussion of course.
	- The feature requires an explicit opt-in so this doesn't bring
	  any new risk to existing crash kernel users until they decide
	  to use it. AFAIU there is no way to tell that the crash kernel
	  memory used to be CMA based in the primary kernel. If you
	  believe that having that information available for
	  debugability would help then I believe this shouldn't be hard
	  to add.  I think it would even make sense to mark this feature
	  experimental to make it clear to users that this needs some
	  time before it can be marked production ready.

I hope I haven't really missed anything important. The final
cost/benefit judgment is up to you, maintainers, of course but I would
like to remind that we are dealing with a _real_ problem that many
production systems are struggling with and that we don't really have any
other solution available.
-- 
Michal Hocko
SUSE Labs