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

[Eugen Hristev <eugen.hristev@linaro.org>]

On 9/16/25 22:27, David Rientjes wrote:
> 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.

Thank you David for getting everyone's expectations more aligned. I am
happy to present everything tomorrow and get feedback on how to find the
best way to get this moving forward with the community.

Eugen