Re: [PATCH] perf: do not flush maps on COMM for perf report

[Arnaldo Carvalho de Melo <acme@ghostprotocols.net>]

Em Wed, Aug 22, 2012 at 09:09:10AM -0700, Luigi Semenzato escreveu:
> On Wed, Aug 22, 2012 at 12:28 AM, Ingo Molnar <mingo@kernel.org> wrote:
> > * Luigi Semenzato <semenzato@chromium.org> wrote:
> >> An alternative patch (which I proposed earlier) would be to
> >> introduce a separate PERF_RECORD_EXEC type, but it is a much
> >> larger change (about 300 lines) and is not necessary.

> > It would be nice to add that too - we already have FORK/EXIT,
> > this seems like a natural extension.

> Yes.  Adding PERF_RECORD_EXEC is/would be the right long-term
> solution.  But there are two issues.

> 1. One nice aspect of perf is that perf.data files and "perf report"
> are compatible across a large number of versions.  Adding
> PERF_RECORD_EXEC breaks compatibility in a somewhat unpleasant manner.
>  New perf.data files won't work with old versions of perf and *might*
> fail poorly (segv) although this situation is difficult to analyze.

> 2. Adding a new record type is messy.  It replicates a lot of
> boilerplate code, much of it in the kernel, and affects many parts of
> the system.  It adds to size, complexity, and likelihood of new bugs.

> I would prioritize the "would be nice" category as follows.

> 1. Improve the handling of unknown record types for future better
> backward compatibility.  (Small change.)

> 2. Refactor/cleanup code to improve readability and robustness.  (Big
> change, but can be broken into many smaller pieces.)

> 3. Add PERF_RECORD_EXEC.

> If there is consensus, I might be able to give a shot to 1 and 2
> (courtesy of Google).

I think this is just common sense, i.e. I'd love to take patches that
improve the robustness of the tools any day.

Refactoring code to make it cleaner and possibly faster and/or smaller,
ditto.

Adding the EXEC event, ditto. And I agree that while adding it we want
to do 1/2 as pre-requisite.

- Arnaldo