From: Steven Rostedt <rostedt@goodmis.org>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Joel Fernandes <joel@joelfernandes.org>,
Peter Zijlstra <peterz@infradead.org>,
Tom Zanussi <zanussi@kernel.org>
Subject: Re: [PATCH 0/2] tracing: Add a way to have custom events in the tracefs directory
Date: Wed, 2 Mar 2022 22:20:11 -0500 [thread overview]
Message-ID: <20220302222011.46102726@rorschach.local.home> (raw)
In-Reply-To: <20220303103101.913c64b92bc7a65e90e22eb1@kernel.org>
On Thu, 3 Mar 2022 10:31:01 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:
> On Tue, 01 Mar 2022 22:24:14 -0500
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > We would like to have in production a way to record sched wakeups and
> > sched switch, and be able to save the information in a small file
> > with as much available as possible. Currently the wake up and sched switch
> > events are 36 and 64 bytes each (plus a 4 byte ring buffer event header).
> >
> > By having a custom module tap into the sched switch and waking trace points
> > we can bring those events down to 16 and 14 bytes respectively.
>
> OK, so we can use eprobe to shrink down the 'visible' log for the event,
> but it still consumes the event buffer because eprobe will fetch the event
> data from the event log. So to reduce the actual consumption of the
> trace buffer, we have to define a new event format and callback.
>
Well, the buffer content itself is shrunk, and we were using eprobes to begin
with for this purpose. The issue is that eprobes still needs to record the
event into a temporary buffer (or the ring buffer then discard it) to
copy the data into the eprobe. This makes using eprobes slower than the
event it is taken from, as the event it is attached to must run first.
Since we have the ability to create a custom module, to do this
directly, and this is much smaller and even a bit faster than the
tracepoints we are attached to.
-- Steve
prev parent reply other threads:[~2022-03-03 3:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-02 3:24 [PATCH 0/2] tracing: Add a way to have custom events in the tracefs directory Steven Rostedt
2022-03-02 3:24 ` [PATCH 1/2] tracing: Allow custom events to be added to " Steven Rostedt
2022-03-02 3:24 ` [PATCH 2/2] tracing: Add sample code for custom trace events Steven Rostedt
2022-03-03 1:40 ` Masami Hiramatsu
2022-03-03 3:23 ` Steven Rostedt
2022-03-03 3:22 ` Joel Fernandes
2022-03-03 3:41 ` Steven Rostedt
2022-03-02 16:00 ` [PATCH 0/2] tracing: Add a way to have custom events in the tracefs directory Joel Fernandes
2022-03-03 1:31 ` Masami Hiramatsu
2022-03-03 3:20 ` Steven Rostedt [this message]
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=20220302222011.46102726@rorschach.local.home \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=zanussi@kernel.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