[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1292957546.2170.21.camel@laptop>
Date: Tue, 21 Dec 2010 19:52:26 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Frederic Weisbecker <fweisbec@...il.com>
Cc: Akihiro Nagai <akihiro.nagai.hw@...achi.com>,
Arnaldo Carvalho de Melo <acme@...radead.org>,
Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
2nddept-manager@....hitachi.co.jp,
Paul Mackerras <paulus@...ba.org>
Subject: Re: [PATCH -tip v2 2/6] perf bts: Introduce new sub command 'perf
bts trace'
On Tue, 2010-12-21 at 19:45 +0100, Frederic Weisbecker wrote:
> On Tue, Dec 21, 2010 at 07:40:32PM +0100, Peter Zijlstra wrote:
> > On Tue, 2010-12-21 at 19:31 +0100, Frederic Weisbecker wrote:
> > > Actually the best would be to select PERF_SAMPLE_ID in the sample_type
> > > on record and also PERF_FORMAT_ID in the read_format.
> >
> > That would grow the data size for little gain, as long as you only
> > record BTS data into the buffer the current bits should work fine.
>
> Indeed.
>
> In the longer term though, I think we need a specific branch set record.
>
> Currently for every branch pair we create a new event with all the headers,
> so the pid, time, etc... are all repeated for every entries.
>
> We rather need a single record everytime we flush the bts buffer to the perf
> buffer.
We also don't want arch specific data interfaces, so we need to iterate
the bts buffer and copy the stuff anyway, and if you don't want the time
and pid bits don't set those PERF_SAMPLE bits.
--
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