[PATCH 00/26] Introduce meminspect

[Steven Rostedt]

On Wed, 19 Nov 2025 20:24:23 +0200
Eugen Hristev <eugen.hristev at linaro.org> wrote:


> The problem is that all the meta-data is not allocated inside the
> preallocated buffer. The meta-data is kmalloced all around the code. I
> mean the structs that hold the information on what's in the buffer. You
> know what I mean.
> And all these kmalloced things, turn out to be in order of hundreds just
> on a kernel boot, which I tested. This is not feasible for the
> meminspect table, as it would get overcrowded very easily.
> I thought of perhaps trying to kmalloc all of them in a dedicated cache,
> but I haven't progressed on that. Another idea would be to try to
> recreate the meta, but I have not found a way to do it yet.>
> > That is, by using the persistent ring buffer code with the meminspect, if
> > the firmware doesn't save the memory across reboots but allows you to dump
> > it to disk, you can enable tracing within the persistent ring buffer, on
> > crash, extract the buffer, and then use trace-cmd to rebuild a trace.dat
> > file that you can now inspect, and see the trace that lead up to the crash.  
> I used 'crash' tool with trace plugin and I am able to see all the trace
> contents, but, with the limitation above. (To achieve this, I dumped a
> huge area to include it, so , not feasible for my goal )

Can't you at boot up just run:

   trace-cmd restore -c -o trace-head.dat

?

That records all the meta data of the running machine, and places it into a
trace-head.dat file. You can save that off anywhere.

Then after a crash, if you split the buffers up into individual cpu raw data
files, you can then run:

  trace-cmd restore -o trace.dat -i trace-head.dat trace-cpu0.raw trace-cpu1.raw ...

And it will create a trace.dat file for you that you can read with:

  trace-cmd report trace.dat

-- Steve