From: Steven Rostedt <rostedt@goodmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Dan Carpenter <dan.carpenter@linaro.org>,
Thorsten Blum <thorsten.blum@toblux.com>
Subject: Re: [GIT PULL] ring-buffer: Updates for 6.11
Date: Fri, 19 Jul 2024 10:32:18 -0400 [thread overview]
Message-ID: <20240719103218.6c1eedfc@rorschach.local.home> (raw)
In-Reply-To: <a71100aa-ffe4-477e-814a-1564e00cb067@efficios.com>
On Tue, 16 Jul 2024 16:05:26 -0400
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> On 2024-07-16 15:51, Steven Rostedt wrote:
> >
> >
> > Linus,
> >
> > tracing/ring-buffer: Have persistent buffer across reboots
>
> Hi Steven,
>
> Perhaps I'm missing something here, but we discussed previously that
> you would document the fact that users of this feature are expected
> to run the same kernel before/after reboot.
>
> Looking at this PR, I fail to find that documentation, or in fact
> any documentation at all. Is this something that was overlooked ?
So I went to update this, and realized there's no place that actually
mentions anything about this being used across reboots (besides in the
change logs). The only documentation is in kernel-parameters.txt:
If memory has been reserved (see memmap for x86), the instance
can use that memory:
memmap=12M$0x284500000 trace_instance=boot_map@0x284500000:12M
The above will create a "boot_map" instance that uses the physical
memory at 0x284500000 that is 12Megs. The per CPU buffers of that
instance will be split up accordingly.
I do plan on adding more documentation on the use cases of this, but I
was planning on doing that in the next merge window when the
reserve_mem kernel parameter can be used. Right now, we only document
what it does, and not what it is used for.
Do you still have an issue with that part missing? No where does it
mention that this is used across boots. There is a file created in the
boot mapped instance directory that hints to the usage
(last_boot_info), but still there's no assumptions made.
In other words, why document a restriction on something that hasn't
been documented?
-- Steve
next prev parent reply other threads:[~2024-07-19 14:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-16 19:51 Steven Rostedt
2024-07-16 20:05 ` Mathieu Desnoyers
2024-07-16 20:11 ` Steven Rostedt
2024-07-16 20:28 ` Mathieu Desnoyers
2024-07-19 14:32 ` Steven Rostedt [this message]
2024-07-19 14:59 ` Mathieu Desnoyers
2024-07-19 16:19 ` Steven Rostedt
2024-07-19 18:05 ` Mathieu Desnoyers
2024-07-19 18:16 ` Steven Rostedt
2024-07-29 22:32 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240719103218.6c1eedfc@rorschach.local.home \
--to=rostedt@goodmis.org \
--cc=dan.carpenter@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=thorsten.blum@toblux.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®