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 [PATCHSET 0/7] perf tools: A couple of TUI improvements (v2) 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.