lkml.org 
[lkml]   [2015]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC/PATCHSET 00/37] perf tools: Speed-up perf report by using multi thread (v1)
Hi Stephane,

On Tue, Jan 06, 2015 at 10:50:44AM -0500, Stephane Eranian wrote:
> On Mon, Jan 5, 2015 at 1:48 PM, Andi Kleen <andi@firstfloor.org> wrote:
> > > This also requires to handle multiple files and to find a
> > > corresponding machine state when processing samples. On a large
> > > profiling session, many tasks were created and exited so pid might be
> > > recycled (even more than once!). To deal with it, I managed to have
> > > thread, map_groups and comm in time sorted. The only remaining thing
> > > is symbol loading as it's done lazily when sample requires it.
> >
> > FWIW there's often a lot of unnecessary information in this
> > (e.g. mmaps that are not used). The Quipper page
> > claims large saving in data files by avoided redundancies.
> >
> > It would be probably better if perf record avoided writing redundant
> > information better (I realize that's not easy)
> > >
> > > With that being done, the stage 2 can be done by multiple threads. I
> > > also save each sample data (per-cpu or per-thread) in separate files
> > > during record. On perf report time, each file will be processed by
> > > each thread. And symbol loading is protected by a mutex lock.
> >
> > I really don't like the multiple files. See above. Also it could easily
> > cause additional seeking on spinning disks.
> >
> having to manage two separate files is a major change which I don't
> particularly like. It will cause problems. I don't see why this cannot
> be appended to the perf.data file with a index at the beginning. There
> is already an index for sections in file mode.

I just thought it's easier to handle with multiple thread. Maybe we
can concatenate the files after recording.


>
> We use the pipe mode a lot and this would not work there. So no,
> I don't like the 2 files solution. But I like the idea of using multiple
> threads to speed up processing.

Actually it's not 2 files, it's 1 + N files. :) Anyway, I think the
single file + index approach requires seeking to process them, is it
ok for pipe-mode?

Thanks,
Namhyung


\
 
 \ /
  Last update: 2015-01-07 09:01    [W:0.086 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site