[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <548EF9C1.2070505@gmail.com>
Date: Mon, 15 Dec 2014 08:09:53 -0700
From: David Ahern <dsahern@...il.com>
To: Adrian Hunter <adrian.hunter@...el.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>
CC: Peter Zijlstra <peterz@...radead.org>,
linux-kernel@...r.kernel.org,
Frederic Weisbecker <fweisbec@...il.com>,
Jiri Olsa <jolsa@...hat.com>,
Namhyung Kim <namhyung@...il.com>,
Paul Mackerras <paulus@...ba.org>,
Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH V3 00/22] perf tools: Introduce an abstraction for Instruction
Tracing
On 12/15/14 2:08 AM, Adrian Hunter wrote:
> On 12/12/14 20:53, Arnaldo Carvalho de Melo wrote:
>> Em Fri, Dec 12, 2014 at 09:13:25AM -0700, David Ahern escreveu:
>>> On 12/12/14 6:47 AM, Adrian Hunter wrote:
>>>> Here is V3 of some more preparatory patches for Intel PT
>>>> that introduce an abstraction for Instruction tracing.
>>
>>> This is an x86-Intel only feature correct? If that is the case then the code
>>> should be not compiled for other architectures.
>
> It is not that simple. In the case of recording, it is not needed for
> architectures that don't support it, but in the case of session processing
> any architecture can (or should be able to) process the perf.data file of
> any other architecture.
Understood. perf is a kitchen sink tool and the size of binaries for
embedded deployments is getting out of hand. e.g., for our PPC based
systems the entire root filesystem is 46M with perf taking up almost 3M
of that (stripped size too). New features need config options so user's
can decide the feature scope of what they are building. And we need to
get the kconfig style builds committed as well.
David
--
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