[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100120153055.GR14636@ghostprotocols.net>
Date: Wed, 20 Jan 2010 13:30:55 -0200
From: Arnaldo Carvalho de Melo <acme@...radead.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Xiao Guangrong <xiaoguangrong@...fujitsu.com>,
Ingo Molnar <mingo@...e.hu>, Paul Mackerras <paulus@...ba.org>,
Frederic Weisbecker <fweisbec@...il.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] perf tools: fix write_event()
Em Wed, Jan 20, 2010 at 03:43:30PM +0100, Peter Zijlstra escreveu:
> On Wed, 2010-01-20 at 15:14 +0100, Peter Zijlstra wrote:
>
> > > > > Uhm, how why? it didn't used to know about events and just copied the
> > > > > data.
> > > >
> > > > looks like acme wrecked it in f5a2c3dc.. anyway the fix is wrong, record
> > > > should not know or care about the actual events and simply write data
> > > > out.
> > >
> > > Oh well, I guess then we should do that after record finishes,
> > > reprocessing all the data in the file.
> >
> > Why do we need it at all?
>
> To clarify, we want to keep the record cycle as small/fast as possible
> in order to minimize permutation of the system we're recording.
This is understood, its the whole reason for us to just record the
build-ids and not try and go reading all the symtabs that appeared on
perf.data.
nstead we just record 20 byte cookies that later will be looked up
somewhere, be it the cache that perf record creates or -debuginfo
packages, or the binary on the fs, whatever matches the buildid and thus
guarantees that we're not doing bogus symbol lookups.
I.e. always trying to defer everything that is possible to post
processing time, at perf report.
- Arnaldo
--
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