Prev: [PATCH] FLAT: allow arches to declare a larger alignment than the slab
Next: sata_nv times out for BD-ROM iHOS104-08
From: Pekka Enberg on 26 May 2010 02:20
On Tue, May 25, 2010 at 11:13 PM, Frederic Weisbecker
<fweisbec(a)gmail.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.
That said, I was probably the only one actually using the feature so
maybe we can just nuke kmemtrace at this point...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Li Zefan on 26 May 2010 03:20
Pekka Enberg wrote:
> On Tue, May 25, 2010 at 11:13 PM, Frederic Weisbecker
> <fweisbec(a)gmail.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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on 26 May 2010 03:50
On Wed, May 26, 2010 at 10:20 AM, Li Zefan <lizf(a)cn.fujitsu.com> wrote:
>> 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.

Sounds good to me.

Acked-by: Pekka Enberg <penberg(a)cs.helsinki.fi>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Eduard - Gabriel Munteanu on 26 May 2010 04:50
On Wed, May 26, 2010 at 03:20:16PM +0800, Li Zefan wrote:
> Pekka Enberg wrote:
> > On Tue, May 25, 2010 at 11:13 PM, Frederic Weisbecker
> > <fweisbec(a)gmail.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.

I don't understand... wasn't the old kmemtrace (the relayfs based stuff)
removed a long time ago? Right now it's just the hooks and code that
sets up tracing and printers.

Or does it happen that that code isn't necessary for 'perf kmem' to do
its job?

And yeah, I'm all for the perf stuff, kmemtrace-user (the out-of-tree
userspace tools) has been obsolete since the shift to ftrace.

As for early tracing, that was possible with the relayfs variant, it
required only the SLAB layer to be up IIRC. But that stopped working
once it got converted to ftrace (kmemtrace_init() is a nop).


Eduard

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Li Zefan on 26 May 2010 05:20
Eduard - Gabriel Munteanu wrote:
> On Wed, May 26, 2010 at 03:20:16PM +0800, Li Zefan wrote:
>> Pekka Enberg wrote:
>>> On Tue, May 25, 2010 at 11:13 PM, Frederic Weisbecker
>>> <fweisbec(a)gmail.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.
>
> I don't understand... wasn't the old kmemtrace (the relayfs based stuff)
> removed a long time ago? Right now it's just the hooks and code that
> sets up tracing and printers.
>
> Or does it happen that that code isn't necessary for 'perf kmem' to do
> its job?
>

Yes, actually the code has nothing to do with perf-kmem.

> And yeah, I'm all for the perf stuff, kmemtrace-user (the out-of-tree
> userspace tools) has been obsolete since the shift to ftrace.
>
> As for early tracing, that was possible with the relayfs variant, it
> required only the SLAB layer to be up IIRC. But that stopped working
> once it got converted to ftrace (kmemtrace_init() is a nop).
>

Ah, thanks for making this clear, so there's no such early tracing
feature that acts as a barrier in removing kmemtrace.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: [PATCH] FLAT: allow arches to declare a larger alignment than the slab
Next: sata_nv times out for BD-ROM iHOS104-08