[lkml]   [2013]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/3] ARM Coresight: Enhance ETM tracing control
On Wed, Dec 04, 2013 at 04:12:56PM -0500, Adrien Vergé wrote:
> 2013/12/4 Greg Kroah-Hartman <>:
> > Your pid implementation is broken, see my other email about that :(
> Thank you for your remarks on pid. I'll try to correct that.
> > And again, what's wrong with the existing tracing functionalty that is
> > processor agnostic? Why can't we just delete this driver today and use
> > the existing trace code?
> As far as I know, the tracing functionality in
> /sys/kernel/debug/tracing does not take advantage of ETM. ETM is a
> dedicated hardware that greatly reduces tracing overhead. It only
> exists on ARM platforms.

How much overhead does the existing tracing code have on ARM? Is ETM
still even needed? Why not just use ETM for the core tracing code

> I understand using sysfs here is not the cleanest way. I patched my
> kernel to meet my needs (trace a specific process or address range),
> and I thought these small modifications could be useful -- until
> bigger work is done to remove ETM control from sysfs.
> Do you think it's worth correcting my patch (for pid namespaces) and
> re-submitting it? Or should we wait for someone to port ETM tracing to
> debugfs?

What's wrong with the in-kernel tracing logic that you can't use that
instead of the ETM stuff?

And no, I don't think adding more functionality to this will be good to
do, ideally it could just be dropped...


greg k-h
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2013-12-05 01:41    [W:0.041 / U:1.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site