From: Steven Rostedt <srostedt@redhat.com>
To: Hiraku TOYOOKA <hiraku.toyooka.gu@hitachi.com>
Cc: linux-kernel@vger.kernel.org, masami.hiramatsu.pt@hitachi.com,
yrl.pp-manager.tt@hitachi.com,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: trace: multiple ring buffers
Date: Tue, 20 Dec 2011 11:45:29 -0500 [thread overview]
Message-ID: <1324399529.2926.14.camel@fedora> (raw)
In-Reply-To: <4EF054B4.7050308@hitachi.com>
Hi Hiraku,
Note, it is usually best to contact me at rostedt@goodmis.org (Cc'd) as
I don't always check this email. I especially don't check it when
traveling, and on holidays (like next week).
On Tue, 2011-12-20 at 18:26 +0900, Hiraku TOYOOKA wrote:
> Hello, Steven,
> I'm researching RAS features for real-time systems.
>
> I'm interested in the multiple ring buffer support on ftrace because of
> following reasons.
Yep, that has been requested before.
>
> * To preserve particular events such as error or fault over a long time. These
> events are useful for failure analysis. But these events could be lost when
> other trace events are generated in large quantities in one buffer. If there is
> only one buffer, we have to prepare one big buffer so that the particular events
> are not overwritten by other events. It wastes memory as a result.
>
> * To use the same trace events for different purposes. For example, I'd like to
> collect trace events and detect performance degradation (using sched_switch
> event, etc.), while running flight recorder for failure analysis.
>
> Multiple buffer support makes these really easy. I'm sure that other users wish
> to use it. Of course, it will introduce some complexities to ftrace code.
Not really. I've always Nack'd the making of the global_ops non-static
for this very reason. The events may need some work, but nothing too
hard.
>
> So, I'd like to implement following the features on ftrace.
>
> * A mechanism to increase buffers on demand
> * A mechanism to change destination buffer(s) of each trace event via debugfs
>
> I have heard from Masami that you have some ideas of multiple buffers. If so,
> could you tell me the ideas? I'd like to cooperate with you to develop multiple
> buffers.
Yeah, basically I figured we create another directory inside the
debugfs/tracing directory. Maybe call it sub_buffers or something.
Inside this directory we could have:
create_buffer - a file that you echo a name into to create a new buffer,
then a directory with that name will appear in this directory.
echo foobar > debugfs/tracing/sub_buffers/create
ls debugfs/tracing/sub_buffers/foobar
buffer_size_kb current_tracer events set_ftrace_filter ...
basically the new directory foobar will be a copy of the debugfs/tracing
directory with a few things possibly missing. Then each of these will be
agnostic to the main tracer.
This was my idea, and I can think of a few issues that will come up, but
nothing that would be a show-stopper.
-- Steve
next prev parent reply other threads:[~2011-12-20 16:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-20 9:26 trace: multiple ring buffers Hiraku TOYOOKA
2011-12-20 16:45 ` Steven Rostedt [this message]
2012-01-06 8:13 ` Hiraku TOYOOKA
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=1324399529.2926.14.camel@fedora \
--to=srostedt@redhat.com \
--cc=hiraku.toyooka.gu@hitachi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=rostedt@goodmis.org \
--cc=yrl.pp-manager.tt@hitachi.com \
/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