Re: [RFC] hotkey for disabling/enabling events in 'perf top' TUI was Re: [GIT PULL 0/8] perf/core improvements and fixes

[Arnaldo Carvalho de Melo]

Em Sat, Jun 20, 2015 at 01:05:40AM +0200, Ingo Molnar escreveu:
> * Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote:
> > Em Fri, Jun 19, 2015 at 08:27:11AM +0200, Ingo Molnar escreveu:
> > > * Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote:
> > > > Em Thu, Jun 18, 2015 at 10:58:13PM +0200, Ingo Molnar escreveu:
> > > > > * Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote:
> > > > > > z             Toggle zeroing of samples 
> > > > > > /             Filter symbol by name 

> > > > > Is 'f' (for 'freeze') still available?

> > > > It is available in both the 'report'/'top' (aka the "hists" browser) and in the 
> > > > annotate browser, so I'll go with it, and leave CTRL+z alone, then make it it 
> > > > suspend.

> > > Sounds good to me!

> > I'm fixing these issues now and a mildly crazy idea ocurred to me: now we can go 
> > from 'top' to 'report' and back, but only if we start in 'perf top', but I think 
> > we could go from 'perf report' to 'perf top' mode too, i.e. start with a 
> > perf.data file, then enable collecting more samples that would then be added to 
> > the existing histograms, etc.
> > 
> > Unsure if this would be useful tho ;-) Its just that it may be easy to do and 
> > would be another step into having it all integrated.
> 
> So I think the following would be useful for perf report: if we recorded the 
> precise command line used, in the perf.data.
> 
> So if someone types:
> 
>     perf record -e cache-misses make -j16 kernel
> 
> then we'd have the whole command line in the perf.data:
> 
>     "perf record -e cache-misses make -j16 kernel"
> 
> and if there was a hotkey to take new samples, using the exact same workload.
> 
> This is non-trivial though.

Right, can be tricky, but we could start with the low hanging fruit:
system wide sessions, then to the other more focussed "live targets",
i.e. existing pids (thread "families"), tids (single threads), CPUs,
cgroups, etc.

Easier because we don't have to recreate a workload, where we may need
to be at a particular cwd, etc.
 
> Going from 'perf report' to 'perf top' would be intuitive if the 'perf record' 
> before was 'perf top' alike, for example:
> 
>     perf record -a sleep 10
> 
> or:
> 
>     perf record -a
>     <Ctrl-C>
> 
> in that case going to 'perf top' is a natural extension of the profiling session.

Agreed, wrote the low hanging fruit part before reading the rest of the
message, obviously ;-)

I.e. ultimately what I would like to achieve would be to merge
builtin-top.c with buildin-report.c and make just the tool name decide
if it starts dynamicly or statically.

At some point 'record' would get merged too, and fully integrated in the
workflow, i.e. one could have at least the following modes:

- record: do nothing more than store the ring buffer in a safe place for
          later processing, be fast at that!

- top: do not record anything, process it straight away and put it into
       histogram buckets according to --sort

- report: do not record anything, process something recorded previously,
          according to --sort

- record + top: do both of these, allow stopping both and looking at
                the last session, or previous ones, allow creating
                slices, etc.

Annotate is already integrated in all this, you can go from either
dynamic or static to annotation and it will show the percentages/periods
per line both staticly and dynamicly.

For slicing, 'probe' integration will come in handy, but the plate is
full already for a while 8-)

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/