All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
	Clark Williams <williams@redhat.com>,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	Adrian Hunter <adrian.hunter@intel.com>,
	Andi Kleen <ak@linux.intel.com>,
	"Gustavo A . R . Silva" <gustavo@embeddedor.com>,
	Thomas Richter <tmricht@linux.ibm.com>,
	Yunfeng Ye <yeyunfeng@huawei.com>,
	Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: Re: [GIT PULL] perf/urgent fixes
Date: Mon, 21 Oct 2019 09:20:28 -0300	[thread overview]
Message-ID: <20191021122028.GA10134@kernel.org> (raw)
In-Reply-To: <20191021062354.GA22042@gmail.com>

Em Mon, Oct 21, 2019 at 08:23:54AM +0200, Ingo Molnar escreveu:
> * Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > 	Please consider pulling,

<SNIP>

> >  tools/perf/util/header.c              |  4 +++-
> >  tools/perf/util/util.c                |  6 ++++--
> >  12 files changed, 65 insertions(+), 17 deletions(-)
 
> Pulled, thanks a lot Arnaldo!

Thanks!
 
> A minor bugreport:
 
> There's a new nuisance message that I noticed when 'perf top' is started: 
> a "vmlinux file has not been found" - with a "press any key" - but the 
> message doesn't actually wait for the keypress, it's cleared on the first 
> screen refresh...

I'll investigate the problems reported after pushing out the current
perf/core lot, thanks for the detailed report!

- Arnaldo
 
> I'd argue that both the keypress action and the warning message is 
> superfluous:
> 
>  - It annoys users while not actually giving any straightforward way to 
>    fix it. It's displayed on every startup of perf top, which is highly 
>    distracting.
> 
>  - At least on Ubuntu it appears to be wrong, because the vmlinux is 
>    available and symbol resolution/annotation appears to be working fine:
> 
> 	# uname -a
> 	Linux dagon 5.4.0-rc3-custom-00557-gb6c81ae120e0 #1 SMP PREEMPT Sun Oct 20 15:28:00 CEST 2019 x86_64 x86_64 x86_64 GNU/Linux
> 
> 	# dpkg -l | grep gb6c81ae120e
> 	ii  linux-headers-5.4.0-rc3-custom-00557-gb6c81ae120e0   5.4.0-rc3-custom-00557-gb6c81ae120e0-1                     amd64        Linux kernel headers for 5.4.0-rc3-custom-00557-gb6c81ae120e0 on amd64
> 	ii  linux-image-5.4.0-rc3-custom-00557-gb6c81ae120e0     5.4.0-rc3-custom-00557-gb6c81ae120e0-1                     amd64        Linux kernel, version 5.4.0-rc3-custom-00557-gb6c81ae120e0
> 	ii  linux-image-5.4.0-rc3-custom-00557-gb6c81ae120e0-dbg 5.4.0-rc3-custom-00557-gb6c81ae120e0-1                     amd64        Linux kernel debugging symbols for 5.4.0-rc3-custom-00557-gb6c81ae120e0
> 	ii  linux-libc-dev:amd64                                 5.4.0-rc3-custom-00557-gb6c81ae120e0-1                     amd64        Linux support headers for userspace development
> 
>    Note that the 'dbg' package is installed which includes the vmlinux, 
>    and perf does seem to find it:
> 
> 	# dpkg-query -L linux-image-5.4.0-rc3-custom-00557-gb6c81ae120e0-dbg | grep vmlinux$
> 	/usr/lib/debug/lib/modules/5.4.0-rc3-custom-00557-gb6c81ae120e0/vmlinux
> 
>    I can see annotated kernel functions just fine.
> 
>  - Finally, when I run perf as root then kallsyms and /proc/kcore is used 
>    to annotate the kernel. So the 'cannot resolve' message cannot even be 
>    true. :-)
> 
> Instead I believe some sort of explanation should be printed in the 
> natural flow when there's an unknown symbol or someone tries to enter a 
> kernel symbol that cannot be further resolved. Even there it probably 
> shouldn't be a 'warning' message, but something printed in-line where 
> usually we'd see the annotated output - to disrupt the normal workflow as 
> little as possible.
> 
> Secondly, there also appears to be a TUI weirdness when the annotated 
> kernel functions are small (or weird): the blue cursor is stuck at the 
> top and I cannot move between the annotated instructions with the down/up 
> arrow:
> 
> Samples: 13M of event 'cycles', 4000 Hz, Event count (approx.): 1272420588851
> clear_page_rep  /usr/lib/debug/boot/vmlinux-5.4.0-rc3-custom-00557-gb6c81ae120e0 [Percent: local period]
>   0.01 │     mov  $0x200,%ecx                                                                                                                                                                      ▒
>        │   xorl %eax,%eax                                                                                                                                                                          ▒
>   0.01 │     xor  %eax,%eax                                                                                                                                                                        ▒
>        │   rep stosq                                                                                                                                                                               ▒
>  99.27 │     rep  stos %rax,%es:(%rdi)                                                                                                                                                             ▒
>        │   ret                                                                                                                                                                                     ▒
>   0.71 │   ← retq                         
> 
> I can still exit the screen with 'q', and can move around in larger 
> annotated kernel functions. Not sure whether it's related to function 
> size, or perhaps to the 'hottest' instruction that the cursor is normally 
> placed at.
> 
> Thanks,
> 
> 	Ingo

-- 

- Arnaldo

  reply	other threads:[~2019-10-21 12:20 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-17 16:02 [GIT PULL] perf/urgent fixes Arnaldo Carvalho de Melo
2019-10-17 16:02 ` [PATCH 01/11] perf jvmti: Link against tools/lib/ctype.h to have weak strlcpy() Arnaldo Carvalho de Melo
2019-10-17 16:02 ` [PATCH 02/11] perf evlist: Fix fix for freed id arrays Arnaldo Carvalho de Melo
2019-10-17 16:02 ` [PATCH 03/11] perf tools: Fix resource leak of closedir() on the error paths Arnaldo Carvalho de Melo
2019-10-17 16:02   ` Arnaldo Carvalho de Melo
2019-10-17 16:02 ` [PATCH 04/11] perf annotate: Fix multiple memory and file descriptor leaks Arnaldo Carvalho de Melo
2019-10-17 16:02 ` [PATCH 05/11] perf tools: Fix mode setting in copyfile_mode_ns() Arnaldo Carvalho de Melo
2019-10-17 16:02 ` [PATCH 06/11] perf c2c: Fix memory leak in build_cl_output() Arnaldo Carvalho de Melo
2019-10-17 16:02 ` [PATCH 07/11] tools headers kvm: Sync kvm headers with the kernel sources Arnaldo Carvalho de Melo
2019-10-17 16:02 ` [PATCH 08/11] " Arnaldo Carvalho de Melo
2019-10-17 16:02 ` [PATCH 09/11] tools headers kvm: Sync kvm.h " Arnaldo Carvalho de Melo
2019-10-17 16:03 ` [PATCH 10/11] tools headers UAPI: Sync sched.h with the kernel Arnaldo Carvalho de Melo
2019-10-17 16:03 ` [PATCH 11/11] perf kmem: Fix memory leak in compact_gfp_flags() Arnaldo Carvalho de Melo
2019-10-21  6:23 ` [GIT PULL] perf/urgent fixes Ingo Molnar
2019-10-21 12:20   ` Arnaldo Carvalho de Melo [this message]
2019-11-06 19:10   ` Arnaldo Carvalho de Melo
2019-11-07  7:02     ` Ingo Molnar
  -- strict thread matches above, loose matches on Subject: below --
2020-04-14 16:48 Arnaldo Carvalho de Melo
2020-04-16 10:07 ` Ingo Molnar
2020-03-09 18:53 Arnaldo Carvalho de Melo
2020-03-19 14:00 ` Ingo Molnar
2020-03-06 19:11 Arnaldo Carvalho de Melo
2020-03-06 21:56 ` Arnaldo Carvalho de Melo
2020-03-07  7:31   ` Ingo Molnar
2020-03-03 19:48 Arnaldo Carvalho de Melo
2020-03-04 10:54 ` Ingo Molnar
2020-02-28 13:59 Arnaldo Carvalho de Melo
2020-02-29  9:11 ` Ingo Molnar
2019-09-21 12:42 Arnaldo Carvalho de Melo
2019-09-22 10:46 ` Ingo Molnar
2019-07-29 21:14 Arnaldo Carvalho de Melo
2019-07-29 21:24 ` Ingo Molnar
2019-07-23 20:05 Arnaldo Carvalho de Melo
2019-07-23 21:42 ` Ingo Molnar

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=20191021122028.GA10134@kernel.org \
    --to=arnaldo.melo@gmail.com \
    --cc=acme@redhat.com \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=gustavo@embeddedor.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tmricht@linux.ibm.com \
    --cc=williams@redhat.com \
    --cc=yeyunfeng@huawei.com \
    /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.