From: Ingo Molnar <mingo@kernel.org>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Mackerras <paulus@samba.org>,
Namhyung Kim <namhyung.kim@lge.com>,
LKML <linux-kernel@vger.kernel.org>, Jiri Olsa <jolsa@redhat.com>,
David Ahern <dsahern@gmail.com>
Subject: Re: [PATCHSET 0/7] perf tools: A couple of TUI improvements (v2)
Date: Fri, 20 Dec 2013 09:13:57 +0100 [thread overview]
Message-ID: <20131220081357.GB12937@gmail.com> (raw)
In-Reply-To: <1387516278-17024-1-git-send-email-namhyung@kernel.org>
* Namhyung Kim <namhyung@kernel.org> wrote:
> Hello,
>
> I was playing with TUI code and added two new windows. One for
> showing log messages and another for showing header information.
> (Maybe they can be implemented on the GTK code too someday.)
>
> * changes from v1)
> - fix segfault on perf top (Ingo)
> - split print function handling patch (Arnaldo)
> - add filtering support on log window (Jiri, Ingo)
>
>
> I put the patches on 'perf/tui-v2' branch in my tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
>
> Any feedbacks are more than welcome, thanks
> Namhyung
Looks pretty good now!
I found four small inconsistencies:
- in 'perf top' the '?' help text states that there's an 'i' key, but
that key does nothing.
- filtering support would be useful in the 'log' window as well :-)
- in both 'perf top' and 'perf report' neither the 'i' nor the 'l'
window shows any help window, so one has to guess that '/' does the
filtering.
- the hotkeys in the help window used to be ordered alphabetically -
they aren't anymore.
While testing 'perf top' I also found three new features which would
be very nice to have, in case you are interested in implementing them:
- it would be nice to have a hotkey to start/stop data collection on
demand, and another hotkey to reset the data. SysProf has this
feature, and it's a convenient workflow to have a separate 'data
collection' period (possibly done without any screen refresh, so
that data collection does not disturb the measured workload), and
a quiet 'look at all the data that is not being changed' period.
Especially with fast changing workloads the latter can be useful.
- it would be nice if 'perf report' had a 'view raw trace' window as
well, with filtering. That would be roughly equivalent to the 'perf
report -D' output [but one line per trace entry, i.e. no hex dump
shown by default], all available within the TUI. With filtering
that would be a pretty good way to look at various details.
- it might also be useful if it was possible to save a perf.data from
a 'perf top' session - and to start a 'perf top' session from a
specific perf.data [and with data collection disabled]. I.e. allow
intermediate modes between 'perf top', 'perf report' and 'perf
record' profiling workflows, all in a single TUI.
Thanks,
Ingo
next prev parent reply other threads:[~2013-12-20 8:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-20 5:11 Namhyung Kim
2013-12-20 5:11 ` [PATCH 1/7] perf report: Use pr_*() functions if possible Namhyung Kim
2014-01-12 18:36 ` [tip:perf/core] perf report: Use pr_*() functions where applicable tip-bot for Namhyung Kim
2013-12-20 5:11 ` [PATCH 2/7] perf report: Print session information only if --stdio is given Namhyung Kim
2014-01-12 18:36 ` [tip:perf/core] " tip-bot for Namhyung Kim
2013-12-20 5:11 ` [PATCH 3/7] perf tools: Introduce struct perf_log Namhyung Kim
2013-12-20 5:11 ` [PATCH 4/7] perf tools: Save message when pr_*() was called Namhyung Kim
2013-12-20 5:11 ` [PATCH 5/7] perf ui/tui: Implement log window Namhyung Kim
2013-12-20 5:11 ` [PATCH 6/7] perf ui/tui: Implement header window Namhyung Kim
2013-12-20 5:11 ` [PATCH 7/7] perf ui/tui: Filter messages in log window Namhyung Kim
2013-12-20 5:21 ` [PATCH v2.1 " Namhyung Kim
2013-12-20 8:13 ` Ingo Molnar [this message]
2013-12-23 5:13 ` [PATCHSET 0/7] perf tools: A couple of TUI improvements (v2) Namhyung Kim
2013-12-23 13:06 ` Ingo Molnar
2013-12-20 17:33 ` Jiri Olsa
2013-12-23 5:23 ` Namhyung Kim
2013-12-23 11:26 ` Jiri Olsa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131220081357.GB12937@gmail.com \
--to=mingo@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=dsahern@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=namhyung.kim@lge.com \
--cc=namhyung@kernel.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome