Re: [Invitation] Linux MM Alignment Session on kmemdump on Wednesday

[David Rientjes <rientjes@google.com>]

On Tue, 16 Sep 2025, Shakeel Butt wrote:

> > >>>> This week's topic will be kmemdump led by Eugen Hristev.  See the latest
> > >>>> proposal at https://lwn.net/Articles/1031319/.
> > >>>
> > >>> I don't understand what this has to do with mm, to be honest.
> > >>> It looks like a debugging aid.
> > >>
> > >> It was suggested to move it to mm/ :
> > >>
> > >> https://lore.kernel.org/all/0fa9e4e7-1247-4c82-8c0b-fa65b7fbb56d@infradead.org/
> > > 
> > > I feel like you should be able to explain this rather better than
> > > "somebody else told me to move it".  As of this moment, I still don't
> > > know what kmemdump even is.
> > > 
> > >>>
> > >>> https://lore.kernel.org/lkml/20250422113156.575971-2-eugen.hristev@linaro.org/
> > >>>
> > >>> is a great example of how to write a lot of documentation that doesn't
> > >>> actually tell the reader what anything is.
> > >>>
> > >>>
> > >>
> > >> Here is a link to the v3 where I changed it a little bit :
> > >>
> > >> https://lore.kernel.org/all/20250912150855.2901211-1-eugen.hristev@linaro.org/
> > >>
> > >> I am eager to improve the documentation to make more sense out of it, I
> > >> am happy with suggestions.
> > > 
> > > Start by telling me what it is.
> > 
> > A way to select memory areas from the kernel that can be used to debug
> > the kernel, instead of saving the whole memory dump which is mostly not
> > of interest and takes a lot of space.
> > Anyone can register a pointer and a size, these are placed into a list,
> > and a dedicated firmware can parse it and save it in case of a crash.
> > Does this make sense ?
> 
> Is it only for kernel or is available for userspace as well? And the
> crashes here, we are talking about kernel crashes or includes process
> crashes as well?
> 

Yeah, I think understanding the scope of this work, both in the current 
RFC as well as the long term vision, is going to be useful.

In this case of kmemdump, which I agree is not core mm, it's likely best 
to use this alignment session to first describe the problem statement: 
what are we trying to solve?  The reference to dedicated firmware above 
piques at least my curiosity.

I see some interaction on the latest RFC, asking questions, and deciding 
the interaction with pstore, I think the goal of this session would be to 
determine if (1) the problem is worth solving, (2) if there are existing 
mechanisms that can already get us there, and (3) if the current approach 
makes sense long term or if any pivots are needed.

Hopefully an interactive discussion will save time in the long term by 
ensuring alignment in this area even if the feedback turns out to be "no, 
we're not doing this."  That would likely best be done by first 
describing, thoroughly, the problem statement before jumping into 
implementation specifics.