Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1310972 > unrolled thread
| Started by | Namhyung Kim <namhyung@kernel.org> |
|---|---|
| First post | 2016-01-16 17:10 +0100 |
| Last post | 2016-01-20 01:20 +0100 |
| Articles | 17 on this page of 77 — 6 participants |
Back to article view | Back to linux.kernel
[RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Namhyung Kim <namhyung@kernel.org> - 2016-01-16 17:10 +0100
[PATCH 16/17] perf hists: Support decaying in hierarchy mode Namhyung Kim <namhyung@kernel.org> - 2016-01-16 17:10 +0100
[PATCH 13/17] perf hists browser: Align column header in hierarchy mode Namhyung Kim <namhyung@kernel.org> - 2016-01-16 17:10 +0100
[PATCH 15/17] perf report: Add --hierarchy option Namhyung Kim <namhyung@kernel.org> - 2016-01-16 17:10 +0100
[PATCH 01/17] perf hists: Basic support of hierarchical report view Namhyung Kim <namhyung@kernel.org> - 2016-01-16 17:10 +0100
Re: [PATCH 01/17] perf hists: Basic support of hierarchical report view Jiri Olsa <jolsa@redhat.com> - 2016-01-17 17:20 +0100
Re: [PATCH 01/17] perf hists: Basic support of hierarchical report view Namhyung Kim <namhyung@kernel.org> - 2016-01-19 12:00 +0100
Re: [PATCH 01/17] perf hists: Basic support of hierarchical report view Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-01-19 18:00 +0100
Re: [PATCH 01/17] perf hists: Basic support of hierarchical report view Jiri Olsa <jolsa@redhat.com> - 2016-01-20 18:10 +0100
Re: [PATCH 01/17] perf hists: Basic support of hierarchical report view Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-01-20 18:20 +0100
Re: [PATCH 01/17] perf hists: Basic support of hierarchical report view Namhyung Kim <namhyung@kernel.org> - 2016-01-21 05:10 +0100
Re: [PATCH 01/17] perf hists: Basic support of hierarchical report view Jiri Olsa <jolsa@redhat.com> - 2016-01-21 11:50 +0100
Re: [PATCH 01/17] perf hists: Basic support of hierarchical report view Namhyung Kim <namhyung@kernel.org> - 2016-01-21 14:00 +0100
Re: [PATCH 01/17] perf hists: Basic support of hierarchical report view Jiri Olsa <jolsa@redhat.com> - 2016-01-21 14:40 +0100
Re: [PATCH 01/17] perf hists: Basic support of hierarchical report view Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-01-21 15:10 +0100
Re: [PATCH 01/17] perf hists: Basic support of hierarchical report view Namhyung Kim <namhyung@kernel.org> - 2016-01-22 11:50 +0100
Re: [PATCH 01/17] perf hists: Basic support of hierarchical report view Namhyung Kim <namhyung@kernel.org> - 2016-01-22 11:50 +0100
Re: [PATCH 01/17] perf hists: Basic support of hierarchical report view Jiri Olsa <jolsa@redhat.com> - 2016-01-22 12:40 +0100
Re: [PATCH 01/17] perf hists: Basic support of hierarchical report view Jiri Olsa <jolsa@redhat.com> - 2016-01-21 12:40 +0100
Re: [PATCH 01/17] perf hists: Basic support of hierarchical report view Namhyung Kim <namhyung@kernel.org> - 2016-01-21 14:10 +0100
[PATCH 08/17] perf hists browser: Fix context menu item Namhyung Kim <namhyung@kernel.org> - 2016-01-16 17:10 +0100
Re: [PATCH 08/17] perf hists browser: Fix context menu item Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-01-21 02:00 +0100
Re: [PATCH 08/17] perf hists browser: Fix context menu item Namhyung Kim <namhyung@kernel.org> - 2016-01-21 05:10 +0100
Re: [PATCH 08/17] perf hists browser: Fix context menu item Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-01-22 01:00 +0100
Re: [PATCH 08/17] perf hists browser: Fix context menu item Namhyung Kim <namhyung@kernel.org> - 2016-01-22 12:10 +0100
Dynamicly add/remove sort keys was: Re: [PATCH 08/17] perf hists browser: Fix context menu item Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-01-22 15:40 +0100
[PATCH 04/17] perf hists: Cleanup filtering functions Namhyung Kim <namhyung@kernel.org> - 2016-01-16 17:10 +0100
Re: [PATCH 04/17] perf hists: Cleanup filtering functions Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-01-19 21:40 +0100
[PATCH v2 04.1/17] perf hists: Remove parent filter check in DSO filter function Namhyung Kim <namhyung@kernel.org> - 2016-01-20 02:30 +0100
[PATCH v2 04.2/17] perf hists: Cleanup filtering functions Namhyung Kim <namhyung@kernel.org> - 2016-01-20 02:30 +0100
Re: [PATCH v2 04.2/17] perf hists: Cleanup filtering functions Jiri Olsa <jolsa@redhat.com> - 2016-01-21 13:10 +0100
Re: [PATCH v2 04.1/17] perf hists: Remove parent filter check in DSO filter function Jiri Olsa <jolsa@redhat.com> - 2016-01-21 13:10 +0100
[PATCH 02/17] perf hists: Resort hist entries with hierarchy Namhyung Kim <namhyung@kernel.org> - 2016-01-16 17:10 +0100
Re: [PATCH 02/17] perf hists: Resort hist entries with hierarchy Jiri Olsa <jolsa@redhat.com> - 2016-01-21 12:50 +0100
Re: [PATCH 02/17] perf hists: Resort hist entries with hierarchy Namhyung Kim <namhyung@kernel.org> - 2016-01-21 14:10 +0100
[PATCH 10/17] perf hists browser: Support collapsing/expanding whole entries in hierarchy Namhyung Kim <namhyung@kernel.org> - 2016-01-16 17:10 +0100
[PATCH 07/17] perf ui/stdio: Align column header for hierarchy output Namhyung Kim <namhyung@kernel.org> - 2016-01-16 17:10 +0100
Re: [PATCH 07/17] perf ui/stdio: Align column header for hierarchy output Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-01-20 23:50 +0100
Re: [PATCH 07/17] perf ui/stdio: Align column header for hierarchy output Namhyung Kim <namhyung@kernel.org> - 2016-01-21 05:10 +0100
[PATCH 12/17] perf hists browser: Implement hierarchy output Namhyung Kim <namhyung@kernel.org> - 2016-01-16 17:10 +0100
[PATCH 05/17] perf hists: Support filtering in hierarchy mode Namhyung Kim <namhyung@kernel.org> - 2016-01-16 17:10 +0100
[PATCH 11/17] perf hists browser: Factor out hist_browser__show_callchain() Namhyung Kim <namhyung@kernel.org> - 2016-01-16 17:10 +0100
[PATCH 06/17] perf ui/stdio: Implement hierarchy output mode Namhyung Kim <namhyung@kernel.org> - 2016-01-16 17:10 +0100
[PATCH 03/17] perf hists: Add helper functions for hierarchy mode Namhyung Kim <namhyung@kernel.org> - 2016-01-16 17:10 +0100
Re: [PATCH 03/17] perf hists: Add helper functions for hierarchy mode Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-01-20 23:20 +0100
Re: [PATCH 03/17] perf hists: Add helper functions for hierarchy mode Namhyung Kim <namhyung@kernel.org> - 2016-01-21 05:00 +0100
[PATCH v2 03/17] perf hists: Add helper functions for hierarchy mode Namhyung Kim <namhyung@kernel.org> - 2016-01-21 05:20 +0100
Re: [PATCH v2 03/17] perf hists: Add helper functions for hierarchy mode Namhyung Kim <namhyung@kernel.org> - 2016-01-21 14:10 +0100
[PATCH 09/17] perf hists browser: Count number of hierarchy entries Namhyung Kim <namhyung@kernel.org> - 2016-01-16 17:10 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Pekka Enberg <penberg@kernel.org> - 2016-01-17 11:30 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Namhyung Kim <namhyung@kernel.org> - 2016-01-19 11:50 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Andi Kleen <andi@firstfloor.org> - 2016-01-17 20:40 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Namhyung Kim <namhyung@kernel.org> - 2016-01-19 11:50 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-01-19 22:10 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-01-19 22:10 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Andi Kleen <andi@firstfloor.org> - 2016-01-19 23:20 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-01-19 23:30 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Namhyung Kim <namhyung@kernel.org> - 2016-01-20 02:00 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Namhyung Kim <namhyung@kernel.org> - 2016-01-20 02:40 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Andi Kleen <andi@firstfloor.org> - 2016-01-20 02:50 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Andi Kleen <andi@firstfloor.org> - 2016-01-20 03:00 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-01-20 14:40 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-01-19 21:10 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-01-19 22:00 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Namhyung Kim <namhyung@kernel.org> - 2016-01-20 01:40 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Andi Kleen <andi@firstfloor.org> - 2016-01-20 06:30 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Taeung Song <taeung.dev@gmail.com> - 2016-01-20 09:00 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Namhyung Kim <namhyung@kernel.org> - 2016-01-20 16:10 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Taeung Song <taeung.dev@gmail.com> - 2016-01-20 17:40 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Namhyung Kim <namhyung@kernel.org> - 2016-01-21 05:20 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Taeung Song <taeung.dev@gmail.com> - 2016-01-21 06:00 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-01-20 14:40 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Namhyung Kim <namhyung@kernel.org> - 2016-01-20 16:10 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-01-20 16:30 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-01-20 16:30 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-01-19 22:00 +0100
Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) Namhyung Kim <namhyung@kernel.org> - 2016-01-20 01:20 +0100
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Andi Kleen <andi@firstfloor.org> |
|---|---|
| Date | 2016-01-20 03:00 +0100 |
| Subject | Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) |
| Message-ID | <qSPUF-7Iz-81@gated-at.bofh.it> |
| In reply to | #1312630 |
On Wed, Jan 20, 2016 at 09:56:47AM +0900, Namhyung Kim wrote: > On Tue, Jan 19, 2016 at 07:24:49PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Tue, Jan 19, 2016 at 11:12:04PM +0100, Andi Kleen escreveu: > > > > > Now we only need a better percent-limit that handles all > > > > > leaves correctly... > > > > > > > > Hmm.. could you tell me where the percent-limit doesn't work > > > > correctly? > > > > > > It doesn't work well together with call chains. > > > > Ok, that is the missing piece of info, lemme check... Yeah that seems > > to be the case. > > So technically this is a callchain issue not a hist entry, right? If Correct. > so, it should be fixed separately. Currently --percent-limit option > works only for hist entries, and for callchain, users should use > -g/--call-graph option. With hierarchy report, we might consider > merging them since it provides continuous interface to callchains.. Ideally it should work all modes, not just hierarchy. > > > > > > It only considers the hits on the leaf function, but doesn't hide > > > the individual call chains leading to that function which are below > > > the limit. > > > > > > So if you have a lot of different cold callers you still end up > > > with far too much output. > > Could you please be more specific? Let me try with an example.. > > $ perf report > ... > + 1.00% perf perf some_function > some_function > - common_caller > - 0.6% caller1 > + 0.4% caller1_1 > + 0.2% caller1_2 > + 0.3% caller2 > + 0.1% caller3 > > In this case, do you want this? > > $ perf report --percent-limit 0.5 > ... > + 1.00% perf perf some_function > some_function > - common_caller > - 0.6% caller1 Right. Only call chains whose total percentage is larger than the limit. > > > > > > > > Also would be nice to be able to set it dynamically from the UI. > > > > To set the mim percent? Yeah, we need to allow setting all those knobs > > from the UI. > > > > I.e. should be like when we press '/' to set a substring filter. > > Yes, how about 'L' key for limit? Fine for me. -Andi -- ak@linux.intel.com -- Speaking for myself only.
[toc] | [prev] | [next] | [standalone]
| From | Arnaldo Carvalho de Melo <acme@kernel.org> |
|---|---|
| Date | 2016-01-20 14:40 +0100 |
| Subject | Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) |
| Message-ID | <qT19o-78z-11@gated-at.bofh.it> |
| In reply to | #1312630 |
Em Wed, Jan 20, 2016 at 09:56:47AM +0900, Namhyung Kim escreveu: > On Tue, Jan 19, 2016 at 07:24:49PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Tue, Jan 19, 2016 at 11:12:04PM +0100, Andi Kleen escreveu: > In this case, do you want this? > $ perf report --percent-limit 0.5 > ... > + 1.00% perf perf some_function > some_function > - common_caller > - 0.6% caller1 > > > Also would be nice to be able to set it dynamically from the UI. > > To set the mim percent? Yeah, we need to allow setting all those knobs > > from the UI. > > I.e. should be like when we press '/' to set a substring filter. > Yes, how about 'L' key for limit? We have other limits we can set, perhaps we should use 'l' and do something like mutt does, i.e. accept expressions that would allow us to have a flexible way of setting limits, not just for the percentage thresholds for hist_entries (callchains later). - Arnaldo
[toc] | [prev] | [next] | [standalone]
| From | Arnaldo Carvalho de Melo <acme@kernel.org> |
|---|---|
| Date | 2016-01-19 21:10 +0100 |
| Subject | Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) |
| Message-ID | <qSKLg-4he-11@gated-at.bofh.it> |
| In reply to | #1310972 |
Em Sun, Jan 17, 2016 at 01:03:00AM +0900, Namhyung Kim escreveu: > Hello, > > This is v2 attempt of my earlier patchset [1]. This patchset > implements a new feature that collects hist entries in a hierachical > manner. That means lower-level entries belong to an upper-level > entry. The entry hierachy is built on the sort keys given, so users > can set it whatever they want. It only shows top-level entries first, > and user can expand/collapse it dynamically. > > This time I implemented it for every output browser including TUI. > A screenshot on TUI looks like below: > > For normal output: > > $ perf report --tui > Samples: 3K of event 'cycles:pp', Event count (approx.): 1695979674 > Overhead Command Shared Object Symbol > ------------------------------------------------------------------------ > - 7.57% swapper [kernel.vmlinux] [k] intel_idle > intel_idle > cpuidle_enter_state > cpuidle_enter > call_cpuidle > + cpu_startup_entry > + 1.16 firefox firefox [.] 0x00000000000019433 > + 0.97% firefox libpthread-2.22.so [.] pthread_mutex_lock > ... > > > With hierarchy view, So, it shows the overhead and the first of the sort keys, "comm", what about the dso, how, from the following output, i.e. the initial screen one gets from 'perf report --tui --hierarchy' we can switch to "dso", i.e. the "Shared Object"? > $ perf report --tui --hierarchy > Samples: 3K of event 'cycles:pp', Event count (approx.): 1695979674 > Overhead Command / Shared Object / Symbol > ------------------------------------------------------------------- > + 76.30% firefox > - 9.95% swapper > - 9.51% [kernel.vmlinux] > - 7.57 [k] intel_idle > intel_idle > cpuidle_enter_state > cpuidle_enter > call_cpuidle > + cpu_startup_entry > + 0.15% [k] __schedule > + 0.12% [k] menu_select > ... > + 0.34% [sdhci] > + 0.06% [e1000e] > ... > + 5.65% Xorg > + 5.42% Socket Thread > ... > > As you can see, overhead of an upper level entry is the sum of > overhead of lower level entries. The entries are aligned by its order > of matching sort keys. > > This is available from 'perf/hierarchy-v2' branch in my tree: > > git://git.kernel.org/pub/scm/linux/kernel/git/namhyung-perf.git > > > Any comments are welcome, thanks! > Namhyung > > > Cc: Don Zickus <dzickus@redhat.com> > Cc: Pekka Enberg <penberg@kernel.org> > Cc: Moinuddin Quadri <moin18@gmail.com> > > > [1] https://lkml.org/lkml/2013/5/21/24 > > > Namhyung Kim (17): > perf hists: Basic support of hierarchical report view > perf hists: Resort hist entries with hierarchy > perf hists: Add helper functions for hierarchy mode > perf hists: Cleanup filtering functions > perf hists: Support filtering in hierarchy mode > perf ui/stdio: Implement hierarchy output mode > perf ui/stdio: Align column header for hierarchy output > perf hists browser: Fix context menu item > perf hists browser: Count number of hierarchy entries > perf hists browser: Support collapsing/expanding whole entries in > hierarchy > perf hists browser: Factor out hist_browser__show_callchain() > perf hists browser: Implement hierarchy output > perf hists browser: Align column header in hierarchy mode > perf ui/gtk: Implement hierarchy output mode > perf report: Add --hierarchy option > perf hists: Support decaying in hierarchy mode > perf top: Add --hierarchy option > > tools/perf/Documentation/perf-report.txt | 3 + > tools/perf/Documentation/perf-top.txt | 3 + > tools/perf/Documentation/tips.txt | 1 + > tools/perf/builtin-report.c | 17 + > tools/perf/builtin-top.c | 15 + > tools/perf/ui/browsers/hists.c | 590 ++++++++++++++++++++++++++----- > tools/perf/ui/gtk/hists.c | 161 ++++++++- > tools/perf/ui/hist.c | 14 + > tools/perf/ui/stdio/hist.c | 182 +++++++++- > tools/perf/util/hist.c | 470 ++++++++++++++++++++---- > tools/perf/util/hist.h | 11 + > tools/perf/util/sort.c | 116 ++++++ > tools/perf/util/sort.h | 16 +- > tools/perf/util/symbol.h | 3 +- > 14 files changed, 1437 insertions(+), 165 deletions(-) > > -- > 2.6.4
[toc] | [prev] | [next] | [standalone]
| From | Arnaldo Carvalho de Melo <acme@kernel.org> |
|---|---|
| Date | 2016-01-19 22:00 +0100 |
| Subject | Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) |
| Message-ID | <qSLxE-4AW-13@gated-at.bofh.it> |
| In reply to | #1310972 |
Em Sun, Jan 17, 2016 at 01:03:00AM +0900, Namhyung Kim escreveu: > Hello, > > This is v2 attempt of my earlier patchset [1]. This patchset > implements a new feature that collects hist entries in a hierachical > manner. That means lower-level entries belong to an upper-level > entry. The entry hierachy is built on the sort keys given, so users > can set it whatever they want. It only shows top-level entries first, > and user can expand/collapse it dynamically. > > This time I implemented it for every output browser including TUI. > A screenshot on TUI looks like below: > > For normal output: > > $ perf report --tui > Samples: 3K of event 'cycles:pp', Event count (approx.): 1695979674 > Overhead Command Shared Object Symbol > ------------------------------------------------------------------------ > - 7.57% swapper [kernel.vmlinux] [k] intel_idle > intel_idle > cpuidle_enter_state > cpuidle_enter > call_cpuidle > + cpu_startup_entry > + 1.16 firefox firefox [.] 0x00000000000019433 > + 0.97% firefox libpthread-2.22.so [.] pthread_mutex_lock > ... > > > With hierarchy view, Ok, tested, this is really nice, I think it should be the default, from where to drill down, we could have a '--no-hierarchy', Ingo? I'll took a quick look patch by patch, seems ok, will try to look deeper to get this merged soon, keep up the great work! - Arnaldo > $ perf report --tui --hierarchy > Samples: 3K of event 'cycles:pp', Event count (approx.): 1695979674 > Overhead Command / Shared Object / Symbol > ------------------------------------------------------------------- > + 76.30% firefox > - 9.95% swapper > - 9.51% [kernel.vmlinux] > - 7.57 [k] intel_idle > intel_idle > cpuidle_enter_state > cpuidle_enter > call_cpuidle > + cpu_startup_entry > + 0.15% [k] __schedule > + 0.12% [k] menu_select > ... > + 0.34% [sdhci] > + 0.06% [e1000e] > ... > + 5.65% Xorg > + 5.42% Socket Thread > ... > > As you can see, overhead of an upper level entry is the sum of > overhead of lower level entries. The entries are aligned by its order > of matching sort keys. > > This is available from 'perf/hierarchy-v2' branch in my tree: > > git://git.kernel.org/pub/scm/linux/kernel/git/namhyung-perf.git > > > Any comments are welcome, thanks! > Namhyung > > > Cc: Don Zickus <dzickus@redhat.com> > Cc: Pekka Enberg <penberg@kernel.org> > Cc: Moinuddin Quadri <moin18@gmail.com> > > > [1] https://lkml.org/lkml/2013/5/21/24 > > > Namhyung Kim (17): > perf hists: Basic support of hierarchical report view > perf hists: Resort hist entries with hierarchy > perf hists: Add helper functions for hierarchy mode > perf hists: Cleanup filtering functions > perf hists: Support filtering in hierarchy mode > perf ui/stdio: Implement hierarchy output mode > perf ui/stdio: Align column header for hierarchy output > perf hists browser: Fix context menu item > perf hists browser: Count number of hierarchy entries > perf hists browser: Support collapsing/expanding whole entries in > hierarchy > perf hists browser: Factor out hist_browser__show_callchain() > perf hists browser: Implement hierarchy output > perf hists browser: Align column header in hierarchy mode > perf ui/gtk: Implement hierarchy output mode > perf report: Add --hierarchy option > perf hists: Support decaying in hierarchy mode > perf top: Add --hierarchy option > > tools/perf/Documentation/perf-report.txt | 3 + > tools/perf/Documentation/perf-top.txt | 3 + > tools/perf/Documentation/tips.txt | 1 + > tools/perf/builtin-report.c | 17 + > tools/perf/builtin-top.c | 15 + > tools/perf/ui/browsers/hists.c | 590 ++++++++++++++++++++++++++----- > tools/perf/ui/gtk/hists.c | 161 ++++++++- > tools/perf/ui/hist.c | 14 + > tools/perf/ui/stdio/hist.c | 182 +++++++++- > tools/perf/util/hist.c | 470 ++++++++++++++++++++---- > tools/perf/util/hist.h | 11 + > tools/perf/util/sort.c | 116 ++++++ > tools/perf/util/sort.h | 16 +- > tools/perf/util/symbol.h | 3 +- > 14 files changed, 1437 insertions(+), 165 deletions(-) > > -- > 2.6.4
[toc] | [prev] | [next] | [standalone]
| From | Namhyung Kim <namhyung@kernel.org> |
|---|---|
| Date | 2016-01-20 01:40 +0100 |
| Subject | Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) |
| Message-ID | <qSOYz-702-75@gated-at.bofh.it> |
| In reply to | #1312511 |
On Tue, Jan 19, 2016 at 05:59:41PM -0300, Arnaldo Carvalho de Melo wrote: > Em Sun, Jan 17, 2016 at 01:03:00AM +0900, Namhyung Kim escreveu: > > Hello, > > > > This is v2 attempt of my earlier patchset [1]. This patchset > > implements a new feature that collects hist entries in a hierachical > > manner. That means lower-level entries belong to an upper-level > > entry. The entry hierachy is built on the sort keys given, so users > > can set it whatever they want. It only shows top-level entries first, > > and user can expand/collapse it dynamically. > > > > This time I implemented it for every output browser including TUI. > > A screenshot on TUI looks like below: > > > > For normal output: > > > > $ perf report --tui > > Samples: 3K of event 'cycles:pp', Event count (approx.): 1695979674 > > Overhead Command Shared Object Symbol > > ------------------------------------------------------------------------ > > - 7.57% swapper [kernel.vmlinux] [k] intel_idle > > intel_idle > > cpuidle_enter_state > > cpuidle_enter > > call_cpuidle > > + cpu_startup_entry > > + 1.16 firefox firefox [.] 0x00000000000019433 > > + 0.97% firefox libpthread-2.22.so [.] pthread_mutex_lock > > ... > > > > > > With hierarchy view, > > Ok, tested, this is really nice, I think it should be the default, from > where to drill down, we could have a '--no-hierarchy', Ingo? Yeah, we already have --no-hierarchy (as a side effect of having --hierarchy) but I don't want to change the default now since existing users will complain. Now we have 'tips' in the perf report browser, maybe it's enough to add a line to suggest to use it (and it's already done by this patchset). I remember the time we changed default for '--children' and many people complained about it. We maybe change the default later but I think it's better to have some time to people can play with it and find it useful. :) And, as always, we can have a config option to control the default. Btw, do you think it's worth adding a short option (-H) for --hierarchy (instead of making it default)? Thanks, Namhyung > > I'll took a quick look patch by patch, seems ok, will try to look deeper > to get this merged soon, > > keep up the great work!
[toc] | [prev] | [next] | [standalone]
| From | Andi Kleen <andi@firstfloor.org> |
|---|---|
| Date | 2016-01-20 06:30 +0100 |
| Subject | Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) |
| Message-ID | <qSTvc-1X3-7@gated-at.bofh.it> |
| In reply to | #1312603 |
> Btw, do you think it's worth adding a short option (-H) for > --hierarchy (instead of making it default)? Yes please. -Andi
[toc] | [prev] | [next] | [standalone]
| From | Taeung Song <taeung.dev@gmail.com> |
|---|---|
| Date | 2016-01-20 09:00 +0100 |
| Subject | Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) |
| Message-ID | <qSVQm-3nE-5@gated-at.bofh.it> |
| In reply to | #1312603 |
On 01/20/2016 09:34 AM, Namhyung Kim wrote:
> On Tue, Jan 19, 2016 at 05:59:41PM -0300, Arnaldo Carvalho de Melo wrote:
>> Em Sun, Jan 17, 2016 at 01:03:00AM +0900, Namhyung Kim escreveu:
>>> Hello,
>>>
>>> This is v2 attempt of my earlier patchset [1]. This patchset
>>> implements a new feature that collects hist entries in a hierachical
>>> manner. That means lower-level entries belong to an upper-level
>>> entry. The entry hierachy is built on the sort keys given, so users
>>> can set it whatever they want. It only shows top-level entries first,
>>> and user can expand/collapse it dynamically.
>>>
>>> This time I implemented it for every output browser including TUI.
>>> A screenshot on TUI looks like below:
>>>
>>> For normal output:
>>>
>>> $ perf report --tui
>>> Samples: 3K of event 'cycles:pp', Event count (approx.): 1695979674
>>> Overhead Command Shared Object Symbol
>>> ------------------------------------------------------------------------
>>> - 7.57% swapper [kernel.vmlinux] [k] intel_idle
>>> intel_idle
>>> cpuidle_enter_state
>>> cpuidle_enter
>>> call_cpuidle
>>> + cpu_startup_entry
>>> + 1.16 firefox firefox [.] 0x00000000000019433
>>> + 0.97% firefox libpthread-2.22.so [.] pthread_mutex_lock
>>> ...
>>>
>>>
>>> With hierarchy view,
>>
>> Ok, tested, this is really nice, I think it should be the default, from
>> where to drill down, we could have a '--no-hierarchy', Ingo?
>
> Yeah, we already have --no-hierarchy (as a side effect of having
> --hierarchy) but I don't want to change the default now since existing
> users will complain. Now we have 'tips' in the perf report browser,
> maybe it's enough to add a line to suggest to use it (and it's already
> done by this patchset). I remember the time we changed default for
> '--children' and many people complained about it.
>
> We maybe change the default later but I think it's better to have some
> time to people can play with it and find it useful. :) And, as always,
> we can have a config option to control the default.
If adding this config option,
can this be included in 'hist' section ?
If it isn't, 'report' and 'top' section ?
i.e.
[report]
hierarchy = true
[top]
hierarchy = false
Thanks,
Taeung
>
> Btw, do you think it's worth adding a short option (-H) for
> --hierarchy (instead of making it default)?
>
> Thanks,
> Namhyung
>
>
>>
>> I'll took a quick look patch by patch, seems ok, will try to look deeper
>> to get this merged soon,
>>
>> keep up the great work!
[toc] | [prev] | [next] | [standalone]
| From | Namhyung Kim <namhyung@kernel.org> |
|---|---|
| Date | 2016-01-20 16:10 +0100 |
| Subject | Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) |
| Message-ID | <qT2yu-8hL-9@gated-at.bofh.it> |
| In reply to | #1312976 |
Hi Taeung, On Wed, Jan 20, 2016 at 04:49:29PM +0900, Taeung Song wrote: > > > On 01/20/2016 09:34 AM, Namhyung Kim wrote: > >On Tue, Jan 19, 2016 at 05:59:41PM -0300, Arnaldo Carvalho de Melo wrote: > >>Em Sun, Jan 17, 2016 at 01:03:00AM +0900, Namhyung Kim escreveu: > >>>Hello, > >>> > >>>This is v2 attempt of my earlier patchset [1]. This patchset > >>>implements a new feature that collects hist entries in a hierachical > >>>manner. That means lower-level entries belong to an upper-level > >>>entry. The entry hierachy is built on the sort keys given, so users > >>>can set it whatever they want. It only shows top-level entries first, > >>>and user can expand/collapse it dynamically. > >>> > >>>This time I implemented it for every output browser including TUI. > >>>A screenshot on TUI looks like below: > >>> > >>>For normal output: > >>> > >>> $ perf report --tui > >>> Samples: 3K of event 'cycles:pp', Event count (approx.): 1695979674 > >>> Overhead Command Shared Object Symbol > >>> ------------------------------------------------------------------------ > >>> - 7.57% swapper [kernel.vmlinux] [k] intel_idle > >>> intel_idle > >>> cpuidle_enter_state > >>> cpuidle_enter > >>> call_cpuidle > >>> + cpu_startup_entry > >>> + 1.16 firefox firefox [.] 0x00000000000019433 > >>> + 0.97% firefox libpthread-2.22.so [.] pthread_mutex_lock > >>> ... > >>> > >>> > >>>With hierarchy view, > >> > >>Ok, tested, this is really nice, I think it should be the default, from > >>where to drill down, we could have a '--no-hierarchy', Ingo? > > > >Yeah, we already have --no-hierarchy (as a side effect of having > >--hierarchy) but I don't want to change the default now since existing > >users will complain. Now we have 'tips' in the perf report browser, > >maybe it's enough to add a line to suggest to use it (and it's already > >done by this patchset). I remember the time we changed default for > >'--children' and many people complained about it. > > > >We maybe change the default later but I think it's better to have some > >time to people can play with it and find it useful. :) And, as always, > >we can have a config option to control the default. > > If adding this config option, > can this be included in 'hist' section ? > If it isn't, 'report' and 'top' section ? > i.e. > > [report] > hierarchy = true > [top] > hierarchy = false Either is fine. But as we already have report.children and top.children, I'd follow the convention. Also I think we should set priority of the two configs - children and hierarchy. IMHO hierarchy should be considered first. Or maybe we could have 'report.output-default' being one of 'hierarchy', 'children', or 'normal'. This way we can set the default behavior easily including possible future changes. Thanks, Namhyung
[toc] | [prev] | [next] | [standalone]
| From | Taeung Song <taeung.dev@gmail.com> |
|---|---|
| Date | 2016-01-20 17:40 +0100 |
| Subject | Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) |
| Message-ID | <qT3XA-HX-7@gated-at.bofh.it> |
| In reply to | #1313277 |
Hi, Namhyung On 01/21/2016 12:08 AM, Namhyung Kim wrote: > Hi Taeung, > > On Wed, Jan 20, 2016 at 04:49:29PM +0900, Taeung Song wrote: >> >> >> On 01/20/2016 09:34 AM, Namhyung Kim wrote: >>> On Tue, Jan 19, 2016 at 05:59:41PM -0300, Arnaldo Carvalho de Melo wrote: >>>> Em Sun, Jan 17, 2016 at 01:03:00AM +0900, Namhyung Kim escreveu: >>>>> Hello, >>>>> >>>>> This is v2 attempt of my earlier patchset [1]. This patchset >>>>> implements a new feature that collects hist entries in a hierachical >>>>> manner. That means lower-level entries belong to an upper-level >>>>> entry. The entry hierachy is built on the sort keys given, so users >>>>> can set it whatever they want. It only shows top-level entries first, >>>>> and user can expand/collapse it dynamically. >>>>> >>>>> This time I implemented it for every output browser including TUI. >>>>> A screenshot on TUI looks like below: >>>>> >>>>> For normal output: >>>>> >>>>> $ perf report --tui >>>>> Samples: 3K of event 'cycles:pp', Event count (approx.): 1695979674 >>>>> Overhead Command Shared Object Symbol >>>>> ------------------------------------------------------------------------ >>>>> - 7.57% swapper [kernel.vmlinux] [k] intel_idle >>>>> intel_idle >>>>> cpuidle_enter_state >>>>> cpuidle_enter >>>>> call_cpuidle >>>>> + cpu_startup_entry >>>>> + 1.16 firefox firefox [.] 0x00000000000019433 >>>>> + 0.97% firefox libpthread-2.22.so [.] pthread_mutex_lock >>>>> ... >>>>> >>>>> >>>>> With hierarchy view, >>>> >>>> Ok, tested, this is really nice, I think it should be the default, from >>>> where to drill down, we could have a '--no-hierarchy', Ingo? >>> >>> Yeah, we already have --no-hierarchy (as a side effect of having >>> --hierarchy) but I don't want to change the default now since existing >>> users will complain. Now we have 'tips' in the perf report browser, >>> maybe it's enough to add a line to suggest to use it (and it's already >>> done by this patchset). I remember the time we changed default for >>> '--children' and many people complained about it. >>> >>> We maybe change the default later but I think it's better to have some >>> time to people can play with it and find it useful. :) And, as always, >>> we can have a config option to control the default. >> >> If adding this config option, >> can this be included in 'hist' section ? >> If it isn't, 'report' and 'top' section ? >> i.e. >> >> [report] >> hierarchy = true >> [top] >> hierarchy = false > > Either is fine. But as we already have report.children and > top.children, I'd follow the convention. Also I think we should set > priority of the two configs - children and hierarchy. IMHO hierarchy > should be considered first. > > Or maybe we could have 'report.output-default' being one of > 'hierarchy', 'children', or 'normal'. This way we can set the default > behavior easily including possible future changes. > Oh, IMHO I think the latter is better than the former. If using 'report.output-default' instead of 'report.children' and 'report.hierarchy' etc integrating the configs, it seems to be tidy. Whatever this config variables will be set as, after this patchset are merged I'll ask about this configs, again. Thanks, Taeung
[toc] | [prev] | [next] | [standalone]
| From | Namhyung Kim <namhyung@kernel.org> |
|---|---|
| Date | 2016-01-21 05:20 +0100 |
| Subject | Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) |
| Message-ID | <qTeT1-8lg-13@gated-at.bofh.it> |
| In reply to | #1313343 |
Hi Taeung, On Thu, Jan 21, 2016 at 01:34:57AM +0900, Taeung Song wrote: > On 01/21/2016 12:08 AM, Namhyung Kim wrote: > >On Wed, Jan 20, 2016 at 04:49:29PM +0900, Taeung Song wrote: > >>On 01/20/2016 09:34 AM, Namhyung Kim wrote: > >>>On Tue, Jan 19, 2016 at 05:59:41PM -0300, Arnaldo Carvalho de Melo wrote: > >>>>Ok, tested, this is really nice, I think it should be the default, from > >>>>where to drill down, we could have a '--no-hierarchy', Ingo? > >>> > >>>Yeah, we already have --no-hierarchy (as a side effect of having > >>>--hierarchy) but I don't want to change the default now since existing > >>>users will complain. Now we have 'tips' in the perf report browser, > >>>maybe it's enough to add a line to suggest to use it (and it's already > >>>done by this patchset). I remember the time we changed default for > >>>'--children' and many people complained about it. > >>> > >>>We maybe change the default later but I think it's better to have some > >>>time to people can play with it and find it useful. :) And, as always, > >>>we can have a config option to control the default. > >> > >>If adding this config option, > >>can this be included in 'hist' section ? > >>If it isn't, 'report' and 'top' section ? > >>i.e. > >> > >>[report] > >> hierarchy = true > >>[top] > >> hierarchy = false > > > >Either is fine. But as we already have report.children and > >top.children, I'd follow the convention. Also I think we should set > >priority of the two configs - children and hierarchy. IMHO hierarchy > >should be considered first. > > > >Or maybe we could have 'report.output-default' being one of > >'hierarchy', 'children', or 'normal'. This way we can set the default > >behavior easily including possible future changes. > > > > Oh, IMHO I think the latter is better than the former. > If using 'report.output-default' instead of 'report.children' > and 'report.hierarchy' etc integrating the configs, > it seems to be tidy. OK > Whatever this config variables will be set as, > after this patchset are merged I'll ask about this configs, again. I'll add you in the CC list wrt config changes. Thanks, Namhyung
[toc] | [prev] | [next] | [standalone]
| From | Taeung Song <taeung.dev@gmail.com> |
|---|---|
| Date | 2016-01-21 06:00 +0100 |
| Subject | Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) |
| Message-ID | <qTfvI-9j-11@gated-at.bofh.it> |
| In reply to | #1313853 |
Hi, Namhyung On 01/21/2016 01:17 PM, Namhyung Kim wrote: > Hi Taeung, > > On Thu, Jan 21, 2016 at 01:34:57AM +0900, Taeung Song wrote: >> On 01/21/2016 12:08 AM, Namhyung Kim wrote: >>> On Wed, Jan 20, 2016 at 04:49:29PM +0900, Taeung Song wrote: >>>> On 01/20/2016 09:34 AM, Namhyung Kim wrote: >>>>> On Tue, Jan 19, 2016 at 05:59:41PM -0300, Arnaldo Carvalho de Melo wrote: >>>>>> Ok, tested, this is really nice, I think it should be the default, from >>>>>> where to drill down, we could have a '--no-hierarchy', Ingo? >>>>> >>>>> Yeah, we already have --no-hierarchy (as a side effect of having >>>>> --hierarchy) but I don't want to change the default now since existing >>>>> users will complain. Now we have 'tips' in the perf report browser, >>>>> maybe it's enough to add a line to suggest to use it (and it's already >>>>> done by this patchset). I remember the time we changed default for >>>>> '--children' and many people complained about it. >>>>> >>>>> We maybe change the default later but I think it's better to have some >>>>> time to people can play with it and find it useful. :) And, as always, >>>>> we can have a config option to control the default. >>>> >>>> If adding this config option, >>>> can this be included in 'hist' section ? >>>> If it isn't, 'report' and 'top' section ? >>>> i.e. >>>> >>>> [report] >>>> hierarchy = true >>>> [top] >>>> hierarchy = false >>> >>> Either is fine. But as we already have report.children and >>> top.children, I'd follow the convention. Also I think we should set >>> priority of the two configs - children and hierarchy. IMHO hierarchy >>> should be considered first. >>> >>> Or maybe we could have 'report.output-default' being one of >>> 'hierarchy', 'children', or 'normal'. This way we can set the default >>> behavior easily including possible future changes. >>> >> >> Oh, IMHO I think the latter is better than the former. >> If using 'report.output-default' instead of 'report.children' >> and 'report.hierarchy' etc integrating the configs, >> it seems to be tidy. > > OK > >> Whatever this config variables will be set as, >> after this patchset are merged I'll ask about this configs, again. > > I'll add you in the CC list wrt config changes. > Thank you! Taeung
[toc] | [prev] | [next] | [standalone]
| From | Arnaldo Carvalho de Melo <acme@kernel.org> |
|---|---|
| Date | 2016-01-20 14:40 +0100 |
| Subject | Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) |
| Message-ID | <qT19o-78z-9@gated-at.bofh.it> |
| In reply to | #1312603 |
Em Wed, Jan 20, 2016 at 09:34:51AM +0900, Namhyung Kim escreveu: > On Tue, Jan 19, 2016 at 05:59:41PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Sun, Jan 17, 2016 at 01:03:00AM +0900, Namhyung Kim escreveu: > > > Hello, > > > > > > This is v2 attempt of my earlier patchset [1]. This patchset > > > implements a new feature that collects hist entries in a hierachical > > > manner. That means lower-level entries belong to an upper-level > > > entry. The entry hierachy is built on the sort keys given, so users > > > can set it whatever they want. It only shows top-level entries first, > > > and user can expand/collapse it dynamically. > > > > > > This time I implemented it for every output browser including TUI. > > > A screenshot on TUI looks like below: > > > > > > For normal output: > > > > > > $ perf report --tui > > > Samples: 3K of event 'cycles:pp', Event count (approx.): 1695979674 > > > Overhead Command Shared Object Symbol > > > ------------------------------------------------------------------------ > > > - 7.57% swapper [kernel.vmlinux] [k] intel_idle > > > intel_idle > > > cpuidle_enter_state > > > cpuidle_enter > > > call_cpuidle > > > + cpu_startup_entry > > > + 1.16 firefox firefox [.] 0x00000000000019433 > > > + 0.97% firefox libpthread-2.22.so [.] pthread_mutex_lock > > > ... > > > > > > > > > With hierarchy view, > > > > Ok, tested, this is really nice, I think it should be the default, from > > where to drill down, we could have a '--no-hierarchy', Ingo? > > Yeah, we already have --no-hierarchy (as a side effect of having > --hierarchy) but I don't want to change the default now since existing > users will complain. Now we have 'tips' in the perf report browser, > maybe it's enough to add a line to suggest to use it (and it's already > done by this patchset). I remember the time we changed default for > '--children' and many people complained about it. :-) Ok, what about an extra patch that, when alt+H is pressed (we're running out of appropriate hotkeys) we toggle to --hierarchy view, press it again, back to --no-hierarchy? > We maybe change the default later but I think it's better to have some > time to people can play with it and find it useful. :) And, as always, > we can have a config option to control the default. > > Btw, do you think it's worth adding a short option (-H) for > --hierarchy (instead of making it default)? I don't think this will remain for long as something we would want to use in the command line, i.e. that we would have about half the number of users wanting one hierarchy while the others wouldn't, for such cases probably the best is to keep it as just a long option? I.e. either the user uses --hierarchy and finds it so useful that he will want to have it as his default or dislikes it and stops passing that option in the command line, end result is that it will be a one time use of such option, no need to have the one letter option used in this case. One thing I just noticed was that right after I ran: $ perf report --hie The tool suggests that I use the brand new '--hierarchy' option :-) How hard would it be to provide a way to disable some of the suggestions when what is randomly suggested is already what the user is doing? - Arnaldo
[toc] | [prev] | [next] | [standalone]
| From | Namhyung Kim <namhyung@kernel.org> |
|---|---|
| Date | 2016-01-20 16:10 +0100 |
| Subject | Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) |
| Message-ID | <qT2yu-8hL-5@gated-at.bofh.it> |
| In reply to | #1313226 |
Hi Arnaldo, On Wed, Jan 20, 2016 at 10:32:04AM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Jan 20, 2016 at 09:34:51AM +0900, Namhyung Kim escreveu: > > On Tue, Jan 19, 2016 at 05:59:41PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Sun, Jan 17, 2016 at 01:03:00AM +0900, Namhyung Kim escreveu: > > > > Hello, > > > > > > > > This is v2 attempt of my earlier patchset [1]. This patchset > > > > implements a new feature that collects hist entries in a hierachical > > > > manner. That means lower-level entries belong to an upper-level > > > > entry. The entry hierachy is built on the sort keys given, so users > > > > can set it whatever they want. It only shows top-level entries first, > > > > and user can expand/collapse it dynamically. > > > > > > > > This time I implemented it for every output browser including TUI. > > > > A screenshot on TUI looks like below: > > > > > > > > For normal output: > > > > > > > > $ perf report --tui > > > > Samples: 3K of event 'cycles:pp', Event count (approx.): 1695979674 > > > > Overhead Command Shared Object Symbol > > > > ------------------------------------------------------------------------ > > > > - 7.57% swapper [kernel.vmlinux] [k] intel_idle > > > > intel_idle > > > > cpuidle_enter_state > > > > cpuidle_enter > > > > call_cpuidle > > > > + cpu_startup_entry > > > > + 1.16 firefox firefox [.] 0x00000000000019433 > > > > + 0.97% firefox libpthread-2.22.so [.] pthread_mutex_lock > > > > ... > > > > > > > > > > > > With hierarchy view, > > > > > > Ok, tested, this is really nice, I think it should be the default, from > > > where to drill down, we could have a '--no-hierarchy', Ingo? > > > > Yeah, we already have --no-hierarchy (as a side effect of having > > --hierarchy) but I don't want to change the default now since existing > > users will complain. Now we have 'tips' in the perf report browser, > > maybe it's enough to add a line to suggest to use it (and it's already > > done by this patchset). I remember the time we changed default for > > '--children' and many people complained about it. > > :-) Ok, what about an extra patch that, when alt+H is pressed (we're > running out of appropriate hotkeys) we toggle to --hierarchy view, press > it again, back to --no-hierarchy? I guess it'd require non-trivial changes to the patchset and add some amount of complexity. I'll check whether it can be done easily later.. > > > We maybe change the default later but I think it's better to have some > > time to people can play with it and find it useful. :) And, as always, > > we can have a config option to control the default. > > > > Btw, do you think it's worth adding a short option (-H) for > > --hierarchy (instead of making it default)? > > I don't think this will remain for long as something we would want to > use in the command line, i.e. that we would have about half the number > of users wanting one hierarchy while the others wouldn't, for such cases > probably the best is to keep it as just a long option? > > I.e. either the user uses --hierarchy and finds it so useful that he > will want to have it as his default or dislikes it and stops passing > that option in the command line, end result is that it will be a one > time use of such option, no need to have the one letter option used in > this case. Some people might find it useful sometimes (or only for specific workloads), but don't want make it default. If they want to use it from time to time, maybe worth adding a short option. > > One thing I just noticed was that right after I ran: > > $ perf report --hie > > The tool suggests that I use the brand new '--hierarchy' option :-) > > How hard would it be to provide a way to disable some of the suggestions > when what is randomly suggested is already what the user is doing? We could add callbacks for each tip to check it. Thanks, Namhyung
[toc] | [prev] | [next] | [standalone]
| From | Arnaldo Carvalho de Melo <acme@kernel.org> |
|---|---|
| Date | 2016-01-20 16:30 +0100 |
| Subject | Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) |
| Message-ID | <qT2RQ-8pt-19@gated-at.bofh.it> |
| In reply to | #1313275 |
Em Thu, Jan 21, 2016 at 12:01:36AM +0900, Namhyung Kim escreveu:
> On Wed, Jan 20, 2016 at 10:32:04AM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Jan 20, 2016 at 09:34:51AM +0900, Namhyung Kim escreveu:
> > > On Tue, Jan 19, 2016 at 05:59:41PM -0300, Arnaldo Carvalho de Melo wrote:
> > One thing I just noticed was that right after I ran:
> > $ perf report --hie
> > The tool suggests that I use the brand new '--hierarchy' option :-)
> > How hard would it be to provide a way to disable some of the suggestions
> > when what is randomly suggested is already what the user is doing?
> We could add callbacks for each tip to check it.
Right, I quickly thought about it and there are some issues, perhaps, in
addition to the existing "unconditional" tips, we could introduce some
way to register conditional tips, something like:
tip__add_cond("For hierarchical output, try: perf report --hierarchy",
&symbol_conf, symbol_conf__is_hierarchy_on);
bool symbol_conf__is_hierarchy_on(const void *parm)
{
const struct symbol_conf *conf = parm;
return conf->report_hierarchy;
}
But then this needs to run after we parse options, so it has to be added
to both builtin-top.c and builtin-report.c and any other tool that needs
to have whatever state evaluated after options are parsed, for state
changed via option parsing.
Yeah, in this specific case we wouldn't need to pass a parameter, as
symbol_conf is global, but just to make the mechanism more general.
Sometimes you'll need to pass say, &report, to have access to state for
'struct report' to look at report.max_stack and check if the user set
--max-stack, etc.
Ah, I should have the hierarchy patches processed today, hopefully
posted to Ingo, thanks for splitting that patch as I asked, appreciated.
- Arnaldo
[toc] | [prev] | [next] | [standalone]
| From | Arnaldo Carvalho de Melo <acme@kernel.org> |
|---|---|
| Date | 2016-01-20 16:30 +0100 |
| Subject | Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) |
| Message-ID | <qT2RQ-8pt-27@gated-at.bofh.it> |
| In reply to | #1313300 |
Em Wed, Jan 20, 2016 at 12:25:48PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Jan 21, 2016 at 12:01:36AM +0900, Namhyung Kim escreveu:
> > On Wed, Jan 20, 2016 at 10:32:04AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Wed, Jan 20, 2016 at 09:34:51AM +0900, Namhyung Kim escreveu:
> > > > On Tue, Jan 19, 2016 at 05:59:41PM -0300, Arnaldo Carvalho de Melo wrote:
> > > One thing I just noticed was that right after I ran:
>
> > > $ perf report --hie
>
> > > The tool suggests that I use the brand new '--hierarchy' option :-)
>
> > > How hard would it be to provide a way to disable some of the suggestions
> > > when what is randomly suggested is already what the user is doing?
>
> > We could add callbacks for each tip to check it.
>
> Right, I quickly thought about it and there are some issues, perhaps, in
> addition to the existing "unconditional" tips, we could introduce some
> way to register conditional tips, something like:
>
> tip__add_cond("For hierarchical output, try: perf report --hierarchy",
> &symbol_conf, symbol_conf__is_hierarchy_on);
>
> bool symbol_conf__is_hierarchy_on(const void *parm)
> {
> const struct symbol_conf *conf = parm;
> return conf->report_hierarchy;
> }
>
> But then this needs to run after we parse options, so it has to be added
> to both builtin-top.c and builtin-report.c and any other tool that needs
> to have whatever state evaluated after options are parsed, for state
> changed via option parsing.
>
> Yeah, in this specific case we wouldn't need to pass a parameter, as
> symbol_conf is global, but just to make the mechanism more general.
>
> Sometimes you'll need to pass say, &report, to have access to state for
> 'struct report' to look at report.max_stack and check if the user set
> --max-stack, etc.
Also say the user used some option, say '--call-graph dwarf', a tip
could notice that and state that one can control the amount of stack to
copy, or tell about some recent improvement about that specific option,
say a speedup, a fix, whatever.
- Arnaldo
[toc] | [prev] | [next] | [standalone]
| From | Arnaldo Carvalho de Melo <acme@kernel.org> |
|---|---|
| Date | 2016-01-19 22:00 +0100 |
| Subject | Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) |
| Message-ID | <qSLxF-4AW-27@gated-at.bofh.it> |
| In reply to | #1310972 |
Em Sun, Jan 17, 2016 at 01:03:00AM +0900, Namhyung Kim escreveu:
> Hello,
>
> This is v2 attempt of my earlier patchset [1]. This patchset
> implements a new feature that collects hist entries in a hierachical
> manner. That means lower-level entries belong to an upper-level
> entry. The entry hierachy is built on the sort keys given, so users
> can set it whatever they want. It only shows top-level entries first,
> and user can expand/collapse it dynamically.
>
> This time I implemented it for every output browser including TUI.
> A screenshot on TUI looks like below:
>
> For normal output:
>
> $ perf report --tui
> Samples: 3K of event 'cycles:pp', Event count (approx.): 1695979674
> Overhead Command Shared Object Symbol
> ------------------------------------------------------------------------
> - 7.57% swapper [kernel.vmlinux] [k] intel_idle
> intel_idle
> cpuidle_enter_state
> cpuidle_enter
> call_cpuidle
> + cpu_startup_entry
> + 1.16 firefox firefox [.] 0x00000000000019433
> + 0.97% firefox libpthread-2.22.so [.] pthread_mutex_lock
> ...
>
>
> With hierarchy view,
>
> $ perf report --tui --hierarchy
> Samples: 3K of event 'cycles:pp', Event count (approx.): 1695979674
> Overhead Command / Shared Object / Symbol
> -------------------------------------------------------------------
> + 76.30% firefox
> - 9.95% swapper
> - 9.51% [kernel.vmlinux]
> - 7.57 [k] intel_idle
> intel_idle
> cpuidle_enter_state
> cpuidle_enter
> call_cpuidle
> + cpu_startup_entry
> + 0.15% [k] __schedule
> + 0.12% [k] menu_select
> ...
> + 0.34% [sdhci]
> + 0.06% [e1000e]
> ...
> + 5.65% Xorg
> + 5.42% Socket Thread
> ...
>
> As you can see, overhead of an upper level entry is the sum of
> overhead of lower level entries. The entries are aligned by its order
> of matching sort keys.
>
> This is available from 'perf/hierarchy-v2' branch in my tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/namhyung-perf.git
Didn't work:
[acme@jouet linux]$ git remote add namhyung git://git.kernel.org/pub/scm/linux/kernel/git/namhyung-perf.git
[acme@jouet linux]$ git remote update namhyung
Fetching namhyung
fatal: remote error: access denied or repository not exported: /pub/scm/linux/kernel/git/namhyung-perf.git
error: Could not fetch namhyung
[acme@jouet linux]$
I looked it up and this one works:
git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
Doing a test merge to test this.
- Arnaldo
[toc] | [prev] | [next] | [standalone]
| From | Namhyung Kim <namhyung@kernel.org> |
|---|---|
| Date | 2016-01-20 01:20 +0100 |
| Subject | Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view (v2) |
| Message-ID | <qSOFc-6QE-37@gated-at.bofh.it> |
| In reply to | #1312513 |
Hi Arnaldo, On Tue, Jan 19, 2016 at 05:52:26PM -0300, Arnaldo Carvalho de Melo wrote: > Em Sun, Jan 17, 2016 at 01:03:00AM +0900, Namhyung Kim escreveu: > > Hello, > > > > This is v2 attempt of my earlier patchset [1]. This patchset > > implements a new feature that collects hist entries in a hierachical > > manner. That means lower-level entries belong to an upper-level > > entry. The entry hierachy is built on the sort keys given, so users > > can set it whatever they want. It only shows top-level entries first, > > and user can expand/collapse it dynamically. > > > > This time I implemented it for every output browser including TUI. > > A screenshot on TUI looks like below: > > > > For normal output: > > > > $ perf report --tui > > Samples: 3K of event 'cycles:pp', Event count (approx.): 1695979674 > > Overhead Command Shared Object Symbol > > ------------------------------------------------------------------------ > > - 7.57% swapper [kernel.vmlinux] [k] intel_idle > > intel_idle > > cpuidle_enter_state > > cpuidle_enter > > call_cpuidle > > + cpu_startup_entry > > + 1.16 firefox firefox [.] 0x00000000000019433 > > + 0.97% firefox libpthread-2.22.so [.] pthread_mutex_lock > > ... > > > > > > With hierarchy view, > > > > $ perf report --tui --hierarchy > > Samples: 3K of event 'cycles:pp', Event count (approx.): 1695979674 > > Overhead Command / Shared Object / Symbol > > ------------------------------------------------------------------- > > + 76.30% firefox > > - 9.95% swapper > > - 9.51% [kernel.vmlinux] > > - 7.57 [k] intel_idle > > intel_idle > > cpuidle_enter_state > > cpuidle_enter > > call_cpuidle > > + cpu_startup_entry > > + 0.15% [k] __schedule > > + 0.12% [k] menu_select > > ... > > + 0.34% [sdhci] > > + 0.06% [e1000e] > > ... > > + 5.65% Xorg > > + 5.42% Socket Thread > > ... > > > > As you can see, overhead of an upper level entry is the sum of > > overhead of lower level entries. The entries are aligned by its order > > of matching sort keys. > > > > This is available from 'perf/hierarchy-v2' branch in my tree: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/namhyung-perf.git > > Didn't work: > > [acme@jouet linux]$ git remote add namhyung git://git.kernel.org/pub/scm/linux/kernel/git/namhyung-perf.git > [acme@jouet linux]$ git remote update namhyung > Fetching namhyung > fatal: remote error: access denied or repository not exported: /pub/scm/linux/kernel/git/namhyung-perf.git > error: Could not fetch namhyung > [acme@jouet linux]$ > > I looked it up and this one works: > > git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git > > Doing a test merge to test this. Oops, sorry about that. I should not type it manually.. Thanks, Namhyung
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | linux.kernel
csiph-web