[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52A0DE42.3080602@codeaurora.org>
Date: Thu, 05 Dec 2013 15:12:50 -0500
From: Christopher Covington <cov@...eaurora.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC: Adrien Vergé <adrienverge@...il.com>,
Russell King <linux@....linux.org.uk>,
Randy Dunlap <rdunlap@...radead.org>,
Will Deacon <will.deacon@....com>,
linux-kernel@...r.kernel.org,
Ben Dooks <ben.dooks@...ethink.co.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
linux-arm-kernel@...ts.infradead.org,
"zhangwei(Jovi)" <jovi.zhangwei@...wei.com>
Subject: Re: [PATCH 0/3] ARM Coresight: Enhance ETM tracing control
Hi Greg,
On 12/04/2013 11:01 PM, Greg Kroah-Hartman wrote:
> On Wed, Dec 04, 2013 at 10:49:25PM -0500, Adrien Vergé wrote:
>> 2013/12/4 Greg Kroah-Hartman <gregkh@...uxfoundation.org>:
>>> 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
>>> instead?
I think support for the Embedded Trace Macrocell is desirable. (Maybe it's not
necesarily *needed*, but in the same way that graphics and audio aren't
necessarily needed when using a desktop machine.) Plugging the ETM into the
core tracing code or maybe into the perf events framework would be
interesting, but do these patches make that work any more difficult?
>> Coresight ETM is not just faster than /sys/kernel/debug/tracing, it
>> provides more detailed and customisable info. For instance, you can
>> trace every load, store, instruction fetch, along with the number of
>> cycles taken, with almost zero-overhead.
>
> Can't you already do that with the 'perf' tool the kernel provides
> without the ETM driver?
With perf one can get a count of how many instructions have been executed,
with little overhead, but not the full list of opcodes and addresses. (One can
also sample the Program Counter intermittently, which might suffice for
performance analysis, but probably doesn't for most debugging use cases.) I
think with perf one can have a handful of watchpoints looking at a very few
loads and stores, with large overhead. As I understand it, ETM can handle
arbitrarily large regions, with little overhead.
Regards,
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
--
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