[Invitation] Linux MM Alignment Session on kmemdump on Wednesday

[Invitation] Linux MM Alignment Session on kmemdump on Wednesday

[David Rientjes]

Hi everybody,

We host a biweekly series, the Linux MM Alignment Session, on Wednesdays.
We'd like to invite MM developers to attend and will announce the topic
for the next instance on the Monday prior to the next meeting.

Our next Linux MM Alignment Session is scheduled for Wednesday.  The
details:

Wednesday, September 17 * 9:00 - 10:00am PDT (UTC-7)
https://meet.google.com/csb-wcds-xya
backup: https://tel.meet/csb-wcds-xya?pin=1301132214803
doc:
https://docs.google.com/document/d/1QQfZFPHa-pGEGf4A06cSqS0jdJwuZ8ro9JU5H0YSUQ0/view

This week's topic will be kmemdump led by Eugen Hristev.  See the latest
proposal at https://lwn.net/Articles/1031319/.

If anybody has ideas for future topics, please let me know and I'll try to 
organize them.  We'd love to have volunteers to lead future topics as well 
as requests for MM topics to be presented.

Looking forward to seeing all of you on Wednesday!

Time zones

PDT (UTC-7)		9:00am
MDT (UTC-6)		10:00am
CDT (UTC-5)		11:00am
EDT (UTC-4)		12:00pm
Rio de Janeiro (UTC-3)	1:00pm
London (UTC+1)		5:00pm
Berlin (UTC+2)		6:00pm
Jerusalem (UTC+3)	7:00pm
Moscow (UTC+3)		7:00pm
Dubai (UTC+4)		8:00pm
Mumbai (UTC+5:30)	9:30pm
Singapore (UTC+8)	12:00am Thursday
Beijing (UTC+8)		12:00am Thursday
Tokyo (UTC+9)		1:00am Thursday
Sydney (UTC+10)		2:00am Thursday
Auckland (UTC+12)	4:00am Thursday

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

[Matthew Wilcox]

On Mon, Sep 15, 2025 at 08:58:35AM -0700, David Rientjes 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.

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.

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

[Eugen Hristev]

On 9/15/25 21:53, Matthew Wilcox wrote:
> On Mon, Sep 15, 2025 at 08:58:35AM -0700, David Rientjes 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/


> 
> 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.

Eugen

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

[Matthew Wilcox]

On Tue, Sep 16, 2025 at 11:49:35AM +0300, Eugen Hristev wrote:
> On 9/15/25 21:53, Matthew Wilcox wrote:
> > On Mon, Sep 15, 2025 at 08:58:35AM -0700, David Rientjes 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.

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

[Eugen Hristev]

On 9/16/25 15:07, Matthew Wilcox wrote:
> On Tue, Sep 16, 2025 at 11:49:35AM +0300, Eugen Hristev wrote:
>> On 9/15/25 21:53, Matthew Wilcox wrote:
>>> On Mon, Sep 15, 2025 at 08:58:35AM -0700, David Rientjes 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 ?

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

[Shakeel Butt]

On Tue, Sep 16, 2025 at 03:14:48PM +0300, Eugen Hristev wrote:
> 
> 
> On 9/16/25 15:07, Matthew Wilcox wrote:
> > On Tue, Sep 16, 2025 at 11:49:35AM +0300, Eugen Hristev wrote:
> >> On 9/15/25 21:53, Matthew Wilcox wrote:
> >>> On Mon, Sep 15, 2025 at 08:58:35AM -0700, David Rientjes 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?

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

[David Rientjes]

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.

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

[Eugen Hristev]

On 9/16/25 18:36, Shakeel Butt wrote:
> On Tue, Sep 16, 2025 at 03:14:48PM +0300, Eugen Hristev wrote:
>>
>>
>> On 9/16/25 15:07, Matthew Wilcox wrote:
>>> On Tue, Sep 16, 2025 at 11:49:35AM +0300, Eugen Hristev wrote:
>>>> On 9/15/25 21:53, Matthew Wilcox wrote:
>>>>> On Mon, Sep 15, 2025 at 08:58:35AM -0700, David Rientjes 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?

Using the crash tool, you can inspect the tasks, current task and other
tasks. You could see the processes and current context.
kmemdump can be used to select also user space regions.
So I suppose you can dump that, but the crash tool would be specifically
used for kernel debugging.
I have not attempted this though. It is interesting to see how it could
work. Maybe kmemdump could create a coredump of a running process, but
it's not attempted as of now.

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

[Eugen Hristev]

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