Re: [PATCHSET 00/16] perf top: Add multi-thread support (v1)

[Arnaldo Carvalho de Melo]

Em Mon, Dec 14, 2015 at 07:55:32AM -0700, David Ahern escreveu:
> On 12/14/15 2:38 AM, Ingo Molnar wrote:
> >
> >>And in an unrelated note, I absolutely detest --buildid being the
> >>default, it makes perf-record blow chunks.
> 
> Yes, a .debug directory that gets bloated fast and being a dot-directory is
> off the primary radar. I forget about it and too often forget to add the
> option to disable it.

Multiple things here, .debug/ should be size limited, and buildid
processing doesn't need necessarily to store things in that cache, I bet
what PeterZ is complaining about is the reprocessing of events at the
end of the session, to find out about the PERF_RECORD_MMAP* events to
then read the build-ids and insert then into the perf.data file header.

All this can be disabled by default, the downside is that when samples
get resolved to something random because the binary used in the session
was replaced by some other we will not be able to notice.

This would be solved by inserting the buildid (20-some bytes) into the
PERF_RECORD_MMAP record, but that remains to be done...
 
> >
> >So I'd absolutely _love_ to split up the singular perf.data into a hierarchy of
> >files in a .perf directory, with a structure like this (4-core system):
> >
> >	.perf/cmdline
> >	.perf/features
> >	.perf/evlist
> >	.perf/ring_buffers/cpu0/raw.trace
> >	.perf/ring_buffers/cpu1/raw.trace
> >	.perf/ring_buffers/cpu2/raw.trace
> >	.perf/ring_buffers/cpu3/raw.trace
> >	...
> 
> On a related note why a .perf directory?
> 
> >
> >I.e. the current single file format of perf.data would be split up into individual
> >files. Each CPU would get its own trace file output - any sorting and ordering
> >would be done afterwards. 'perf record' itself would never by default have to do
> >any of that, it's a pure recording session.
> >
> >'perf archive' would still create a single file to make transport between machines
> >easy.
> >
> >perf.data.old would be replaced by a .perf.old directory or so.
> >
> >Debugging would be easier too I think, as there's no complex perf data format
> >anymore, it's all in individual (typically text, or binary dump) files in the
> >.perf directory.
> >
> >This would solve all the scalability problems - and would make the format more
> >extensible and generally more accessible as well.
> >
> >What do you think?
> 
> Big change to user experience.
> 
> I realize perf-archive has been around since I started using perf in
> mid-2010, but I for one never use it. I suspect it is not widely used
> (definitely not in the circles I have been involved and helped with perf),
> so suddenly requiring it is a change in user experience.
> 
> The only 2 files on the system I pull off the box are kallsyms and
> perf.data. Most of the systems where I use perf have limited symbols and
> there is nothing in .debug I need to pull of the box.

Well, we don't have to use perf archive for that, doing what Ingo
suggests and on top of it putting it into a perf.data file that in fact
is a cpio or tarball would keep the one-file while introducing the split
up for later processing bits.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/