[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4BFCCBB0.6040101@cn.fujitsu.com>
Date: Wed, 26 May 2010 15:20:16 +0800
From: Li Zefan <lizf@...fujitsu.com>
To: Pekka Enberg <penberg@...helsinki.fi>
CC: Frederic Weisbecker <fweisbec@...il.com>,
Chase Douglas <chase.douglas@...onical.com>,
Prasad <prasad@...ux.vnet.ibm.com>,
Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>,
Soeren Sandmann <sandmann@...mi.au.dk>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: Tracing configuration review
Pekka Enberg wrote:
> On Tue, May 25, 2010 at 11:13 PM, Frederic Weisbecker
> <fweisbec@...il.com> wrote:
>>> # CONFIG_KMEMTRACE is not set (Kconfig says N if unsure)
>> Deprecated. We have the kmem trace event that are a full replacement now.
>> Pekka, Gabriel, can we remove it now?
>
> I don't think ftrace supports boot-time tracing which kmemtrace did.
We can do boot-time tracing by passing "trace_event=" kernel parameter.
By passing "ftrace=kmemtrace", kmemtrace can be started when
calling tracer_alloc_buffer(), which is an early_initcall.
While trace events are inititialized as a fs_initcall, it can
be modified to an early_initcall.
Furthermore, I noticed the discussion on perf persistent events, which
seems to enable perf trace at boot time, so I think perf-kmem can take
advantage of this and will be a full-replacement of kmemtrace soon ?
> That said, I was probably the only one actually using the feature so
> maybe we can just nuke kmemtrace at this point...
If you agree on removing kmemtrace now, I'll re-send the patch.
--
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/
Powered by blists - more mailing lists