Re: Scrolling down broken with "perf top --hierarchy"

From: Taeung Song
Date: Wed Oct 26 2016 - 20:47:14 EST


Sorry for late reply, Namhyung

On 10/25/2016 01:37 AM, Namhyung Kim wrote:
Hi Taeung,

On Mon, Oct 24, 2016 at 07:10:24PM +0900, Taeung Song wrote:
Hi, Namhyung and Arnaldo :)

On 10/24/2016 02:11 PM, Namhyung Kim wrote:
Hi Arnaldo,

Sorry for late reply.

On Fri, Oct 07, 2016 at 11:35:45AM -0300, Arnaldo Carvalho de Melo wrote:
Em Fri, Oct 07, 2016 at 01:53:57PM +0900, Namhyung Kim escreveu:
Cc-ing perf maintainers,

On Fri, Oct 07, 2016 at 06:32:29AM +0200, Markus Trippelsdorf wrote:
On 2016.10.07 at 13:22 +0900, Namhyung Kim wrote:
On Fri, Oct 07, 2016 at 05:51:18AM +0200, Markus Trippelsdorf wrote:
On 2016.10.07 at 10:17 +0900, Namhyung Kim wrote:
On Thu, Oct 06, 2016 at 06:33:33PM +0200, Markus Trippelsdorf wrote:
Scrolling down is broken when using "perf top --hierarchy".
When it starts up everything is OK and one can scroll up and down to all
entries. But as further and further new entries get added to the list,
scrolling down is blocked (at the position of the last entry that was
shown directly after startup).

I think below patch will fix the problem. Please check.

Yes. It works fine now. Many thanks.

Good. Can I add your Tested-by then?

Sure.

Ok, I'll send a formal patch with it.


(And in the long run you should think of making "perf top --hierarchy"
the default for perf top, because it gives a much better (uncluttered)
overview of what is going on.)

I think it's a matter of taste. Some people prefer to see the top
single function or something (i.e. current behavior) while others
prefer to see a higher-level view.

But we can think again about the default at least for perf-top. I
worried about changing default behavior because last time we did it
for children mode many people complained about it. But I do think the
hierarchy mode is useful for many people though.

So, I think in such cases we could experiment with asking the user about
switching to the new mode by showing a popup message telling what it is
about, if the user says "yes, I want to try it" switch to it and if
another hotkey is pressed later, write what was chosen (yes, switch to
this new mode, no, I don't like it, don't pester me about it anymore) to
its ~/.perfconfig file so that next time it goes straight to this new
mode, else don't ask the user again and keep using whatever mode was
there already.

What do you think?

I think it's a flexible way to set the default behavior while it seems
like a little bit complicated for implementation. Also I think it's
better to popup another dialog at the end and asks for comfirmation
(but it might not be appropriate for --stdio).

And to do that, we need to have a (programmable) way of dealing with
the configs.

Taeung, is there an update on your config patchset (especially for
write support)?


Is related this link with what you said ?
https://lkml.org/lkml/2016/1/11/495

Yep, that kind of thing.


Yes, the config patchset would be need to be updated.
Because the config patchset which has 'write' feature
don't use a recent 'struct perf_config_set' so I should change it
to use 'perf_config_set' like show_config() of builtin-config.c:36.

Do you need write support of perf-config command ?
If this feature is more necessary than a recent patchset about default
config array https://lkml.org/lkml/2016/9/5/17,
I'd remake config patchset for getting and setting features first. :)

What I need is a way to add a config item with specific value. Maybe
I can just append a line into a config file, but it needs to check
possible conflict somehow. So I think it needs to process existing
config items properly and update with the new value.


I got it. Understood what you said!
I'll send a patchset for this. :)

Thanks,
Taeung