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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.