Prev: ACPI, APEI, PCIE AER, use general HEST table parsing in AER firmware_first setup
Next: GFS2: Pull request
From: Arnaldo Carvalho de Melo on 7 Mar 2010 13:10
Em Sun, Mar 07, 2010 at 11:35:31AM +0200, Avi Kivity escreveu:
> perf really is wonderful, but to be really competitive, and usable to
> more developers, it needs to be in a graphical environment. I want
> 'perf report' output to start out collapsed and drill down by clicking
> on a tree widget. Clicking on a function name opens its definition.
> 'perf annotate' should display annotations on my editor window, not in a
> pager. I should be able to check events on a list, not using 'perf
> list'.

Do you really think that more kernel developers would use perf more
frequently if it had some GUI?

I plan to work on a ncurses tool combining aspects of the existing perf
tools, integrating them more, like you suggest above, but even having
worked on a pygtk tool that is close to the kernel [1], I'm unsure if
doing it using gtk or QT would be something that would entice more
developers to use it.

- Arnaldo

[1] http://www.osadl.org/Single-View.111+M52212cb1379.0.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 7 Mar 2010 13:20
On 03/07/2010 08:01 PM, Arnaldo Carvalho de Melo wrote:
> Em Sun, Mar 07, 2010 at 11:35:31AM +0200, Avi Kivity escreveu:
>
>> perf really is wonderful, but to be really competitive, and usable to
>> more developers, it needs to be in a graphical environment. I want
>> 'perf report' output to start out collapsed and drill down by clicking
>> on a tree widget. Clicking on a function name opens its definition.
>> 'perf annotate' should display annotations on my editor window, not in a
>> pager. I should be able to check events on a list, not using 'perf
>> list'.
>>
> Do you really think that more kernel developers would use perf more
> frequently if it had some GUI?
>

Not much. Is perf's target kernel developers exclusively? Who are we
writing this kernel for?

No wonder everything is benchmarked using kbuild.

> I plan to work on a ncurses tool combining aspects of the existing perf
> tools, integrating them more, like you suggest above, but even having
> worked on a pygtk tool that is close to the kernel [1], I'm unsure if
> doing it using gtk or QT would be something that would entice more
> developers to use it.
>

Even for kernel developers there are advantages in a GUI, namely that
features are easily discovered, the amount of information is easily
controlled, and in that you can interact (not redo everything from
scratch every time you want to change something). The difference
between a curses based tool and a true GUI are minimal for this audience.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 7 Mar 2010 13:20
On 03/07/2010 05:14 PM, Luca Barbieri wrote:
>> perf really is wonderful, but to be really competitive, and usable to more
>> developers, it needs to be in a graphical environment. I want 'perf report'
>> output to start out collapsed and drill down by clicking on a tree widget.
>> Clicking on a function name opens its definition. 'perf annotate' should
>> display annotations on my editor window, not in a pager. I should be able
>> to check events on a list, not using 'perf list'.
>>
>> Is something like that suitable for tools/perf/? I think you'll find the
>> intersection of kernel developers and GUI developers to be fairly small.
>>
> The latest versions of Gnome Sysprof use perf and provide a GTK+ tree
> interface for the profiling output.
>
> However, they are not configurable at all and don't support anything
> but call graph profiling, unless they added more features very
> recently.
> It would be nice to extend sysprof into a more capable tool, and one
> that can read perf output files and do so when launched from the
> command line.
>

Looks like a step in the right direction. I don't think this belong in
tools/, though.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 7 Mar 2010 13:50

* Pekka Enberg <penberg(a)cs.helsinki.fi> wrote:

> That said, AFAICT, it should be pretty simple to implement a shark-like UI
> with GTK as current perf code is pretty good fit for that. I've pondered
> about doing that myself but quite frankly, I don't see any big gains in
> that.

There's a perf events based GUI: sysprof.

It's not integrated into tools/perf/ (it's using the syscall) and we'd welcome
it integrated as 'perf view' or 'perf gui' - just like we'd welcome a new
from-scratch GUI frontend as well.

The latter would have the advantage of growing gradually and naturally - so if
you feel like implementing it, please do not hesitate ;-) I had a good hard
look at the perf GUI situation a few months ago and GTK looks like the best
fit.

Even if it's simple initially it would clearly show us the exact demand of GUI
versus TUI. I.e. if you are right and it doesnt matter, it will stay simple,
if Avi is right and it matters then people will use it as a base and improve
it. A win-win scenario.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arnaldo Carvalho de Melo on 7 Mar 2010 14:00
Em Sun, Mar 07, 2010 at 08:15:40PM +0200, Avi Kivity escreveu:
> On 03/07/2010 08:01 PM, Arnaldo Carvalho de Melo wrote:
> >Em Sun, Mar 07, 2010 at 11:35:31AM +0200, Avi Kivity escreveu:
> >>perf really is wonderful, but to be really competitive, and usable to
> >>more developers, it needs to be in a graphical environment. I want
> >>'perf report' output to start out collapsed and drill down by clicking
> >>on a tree widget. Clicking on a function name opens its definition.
> >>'perf annotate' should display annotations on my editor window, not in a
> >>pager. I should be able to check events on a list, not using 'perf
> >>list'.
> >Do you really think that more kernel developers would use perf more
> >frequently if it had some GUI?
>
> Not much. Is perf's target kernel developers exclusively? Who are
> we writing this kernel for?

No, we aren't writing this tool only for kernel developers exclusively,
but that wasn't my question, it was badly formulated, sorry, I shouldn't
have included "kernel" in it :-\

> No wonder everything is benchmarked using kbuild.
>
> >I plan to work on a ncurses tool combining aspects of the existing perf
> >tools, integrating them more, like you suggest above, but even having
> >worked on a pygtk tool that is close to the kernel [1], I'm unsure if
> >doing it using gtk or QT would be something that would entice more
> >developers to use it.
>
> Even for kernel developers there are advantages in a GUI, namely
> that features are easily discovered, the amount of information is
> easily controlled, and in that you can interact (not redo everything
> from scratch every time you want to change something). The
> difference between a curses based tool and a true GUI are minimal
> for this audience.

Ok, I agree with you about easier discoverability of features, path
shortened from report to annotate to starting the editor right at the
line where some event of interest happened, will try to keep the
routines not much coupled with ncurses, but definetely ncurses will be
the first step.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: ACPI, APEI, PCIE AER, use general HEST table parsing in AER firmware_first setup
Next: GFS2: Pull request