linux-kernel - Re: [RFC] tracing: Adding cgroup aware tracing functionality

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]

Message-ID: <BANLkTikOi1Y_5RH1juPmchWHjW8f=ynuRA@mail.gmail.com>
Date:	Fri, 8 Apr 2011 11:32:53 -0700
From:	Michael Rubin <mrubin@...gle.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	David Sharp <dhsharp@...gle.com>,
	Vaibhav Nagarnaik <vnagarnaik@...gle.com>,
	Paul Menage <menage@...gle.com>,
	Li Zefan <lizf@...fujitsu.com>,
	Stephane Eranian <eranian@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ken Chen <kenchen@...gle.com>, linux-kernel@...r.kernel.org,
	containers@...ts.linux-foundation.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [RFC] tracing: Adding cgroup aware tracing functionality

Minor history, Google wrote ktrace which we started to push upstream
and then jumped on the ftrace train. ftrace was a very good drop in
replacement for us. ftrace has a lot of features ktrace did not. We
use perf also in other contexts.

We have devoted a lot of time and energy from many engineers outside
of kernel to use ftrace. It's not just the kernel code, but we have
built a lot of sw on ftrace as we examine systems in the cloud. It was
not easy to make this migration since it had a lot of user impact. It
was less the low level API but the fact that the tracepoints semantics
had changed. Google is in the process of no longer using ktrace.

Requirements for tracing for us seem to be:
1) Around 250ns latencies when enabled
2) Small events - We have worked on shrinking the ftrace event size.
Since we are constrained on the amount of memory we can use in the
ring buffer, every byte counts. A nice sized event is on the order of
<= 8 bytes. Some of the 2.6.34 ftrace events like irq_enter and exit
were too big around 20 bytes. sched_switch is around 60 bytes.

I am not sure that perf meets these requirements. We need to use
ftrace for tracing _now_.  Google also needs to focus on improving
ftrace upstream so we can contribute our changes to the community. We
are submitting patches and working with upstream to improve ftrace.
Currently we depend on ftrace and being around for a long time.

Fredric wrote:" Nonetheless you can't be such a significant
user/developer of the upstream kernel tracing and at the same time
ignore some key problems of the actual big picture of it."

I see less of a big picture issue and more of an awkward two pictures.
>From my view it's a question of whether ftrace should continue to be
supported and improved or whether perf will do everything as well and
when. We depend on ftrace today and as such we have invested our time
there.

mrubin
--
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/