[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210421110006.3652f26a@gandalf.local.home>
Date: Wed, 21 Apr 2021 11:00:06 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Rasmus Villemoes <linux@...musvillemoes.dk>
Cc: Dan Williams <dan.j.williams@...el.com>,
"fweisbec@...il.com" <fweisbec@...il.com>,
"jeyu@...nel.org" <jeyu@...nel.org>,
"mathieu.desnoyers@...icios.com" <mathieu.desnoyers@...icios.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"mingo@...e.hu" <mingo@...e.hu>,
"chris@...is-wilson.co.uk" <chris@...is-wilson.co.uk>,
"yuanhan.liu@...ux.intel.com" <yuanhan.liu@...ux.intel.com>,
"Grumbach, Emmanuel" <emmanuel.grumbach@...el.com>
Subject: Re: [PATCH][RFC] tracing: Enable tracepoints via module parameters
On Wed, 21 Apr 2021 16:50:30 +0200
Rasmus Villemoes <linux@...musvillemoes.dk> wrote:
> I don't "want" anything. I just fail to see what advantage that proof of
> concept would bring over the current dev_dbg implementation.
That you don't need to go through the console. The trace ring buffer is
much faster than printk (you can record millions of traces a second,
and barely notice the overhead, which is why you can trace scheduling and
high frequency interrupts), and if you want, you get your very own buffer
to record to, without any noise from anything else, with features like
filtering, histograms, stack traces, etc.
The tracing infrastructure has a lot more to offer than printk does.
-- Steve
Powered by blists - more mailing lists