linux-kernel - Re: trace: multiple ring buffers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 20 Dec 2011 11:45:29 -0500
From:	Steven Rostedt <srostedt@...hat.com>
To:	Hiraku TOYOOKA <hiraku.toyooka.gu@...achi.com>
Cc:	linux-kernel@...r.kernel.org, masami.hiramatsu.pt@...achi.com,
	yrl.pp-manager.tt@...achi.com, Steven Rostedt <rostedt@...dmis.org>
Subject: Re: trace: multiple ring buffers

Hi Hiraku,

Note, it is usually best to contact me at rostedt@...dmis.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/