[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220701135723.12b4f179@gandalf.local.home>
Date: Fri, 1 Jul 2022 13:57:23 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Joel Fernandes <joel@...lfernandes.org>
Cc: Rob Herring <robh+dt@...nel.org>,
Nachammai Karuppiah <nachukannan@...il.com>,
Ingo Molnar <mingo@...hat.com>,
Frank Rowand <frowand.list@...il.com>,
Kees Cook <keescook@...omium.org>,
Anton Vorontsov <anton@...msg.org>,
Colin Cross <ccross@...roid.com>,
Tony Luck <tony.luck@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>,
Brian Norris <computersforpeace@...il.com>
Subject: Re: [RFC PATCH 0/7] Trace events to pstore
On Fri, 1 Jul 2022 12:53:17 -0400
Joel Fernandes <joel@...lfernandes.org> wrote:
> Interesting. In the case of pstore, you know exactly where the pages
> are for ftrace. How would you know that for the buddy system where
> pages are in the wild wild west? I guess you would need to track where
> ftrace pages where allocated, within the crash dump/report.
kexec/kdump already does that (of course it requires the DWARF symbols of
the kernel to be accessible by the kdump kernel).
But if we write the raw ftrace data into persistent memory that can survive
a reboot, then we can extract that raw data and convert it back to text
offline.
Thus, I would like to remove the converting to text and compressing into
pstore, and possibly look at a solution that simply writes the raw data
into pstore.
-- Steve
Powered by blists - more mailing lists