From: Steven Rostedt <rostedt@goodmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux Trace Kernel <linux-trace-kernel@vger.kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Sachin Sant <sachinp@linux.ibm.com>
Subject: Re: [PATCH] tracing: Have trace_marker writes be just half of TRACE_SEQ_SIZE
Date: Mon, 4 Mar 2024 20:57:30 -0500 [thread overview]
Message-ID: <20240304205730.53328530@gandalf.local.home> (raw)
In-Reply-To: <e34628b6-fdb3-420f-8563-4cf91ad3a04b@efficios.com>
On Mon, 4 Mar 2024 20:36:28 -0500
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> > <...>-999 [001] ..... 2296.140373: tracing_mark_write: hello
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > This is the meta data that is added to trace_seq
>
> If this header has a known well-defined upper-limit length, then use
> that in the BUILD_BUG_ON().
Unfortunately there's no set limit. It's built up by different callbacks
and such. The output can be changed by options set by the user and even by
tracers, like the function graph tracer:
# tracer: function_graph
#
# CPU DURATION FUNCTION CALLS
# | | | | | | |
1) | /* hello */
But the worse that will happen if it overflows is that the event is
replaced with:
<...>-999 [001] ..... 2296.140373: [LINE TOO BIG]
But this has never happened outside of development. I guess you could
trigger it if you add a trace_printk() that has a string bigger than
TRACE_SEQ_BUFFER_SIZE. But as Linus says, "Don't do stupid things" ;-)
But in reality, with all the options and everything, I've never seen the
appended text more than 80 bytes (and probably much less).
-- Steve
next prev parent reply other threads:[~2024-03-05 1:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-05 0:27 [PATCH] tracing: Have trace_marker writes be just half of TRACE_SEQ_SIZE Steven Rostedt
2024-03-05 0:43 ` Randy Dunlap
2024-03-05 0:49 ` Steven Rostedt
2024-03-05 1:15 ` Mathieu Desnoyers
2024-03-05 1:35 ` Steven Rostedt
2024-03-05 1:36 ` Mathieu Desnoyers
2024-03-05 1:57 ` Steven Rostedt [this message]
2024-03-05 1:41 ` Steven Rostedt
2024-03-05 1:42 ` Mathieu Desnoyers
2024-03-05 1:59 ` Steven Rostedt
2024-03-05 2:18 ` Mathieu Desnoyers
2024-03-05 2:35 ` Steven Rostedt
2024-03-05 2:37 ` Steven Rostedt
2024-03-05 2:48 ` Mathieu Desnoyers
2024-03-05 3:07 ` 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=20240304205730.53328530@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=sachinp@linux.ibm.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