public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Jiri Olsa <jolsa@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH] perf tools: session: avoid infinite loop
Date: Fri, 18 Sep 2015 10:51:13 +0100	[thread overview]
Message-ID: <20150918095112.GA21286@leverpostej> (raw)
In-Reply-To: <55FBAA8C.2020703@intel.com>

On Fri, Sep 18, 2015 at 07:09:16AM +0100, Adrian Hunter wrote:
> On 17/09/15 18:41, Mark Rutland wrote:
> > Hi,
> > 
> > On Wed, Sep 16, 2015 at 09:54:54PM +0100, Arnaldo Carvalho de Melo wrote:
> >> Em Wed, Sep 16, 2015 at 06:18:49PM +0100, Mark Rutland escreveu:
> >>> This has been observed to result in an exit-time hang when counting
> >>> rare/unschedulable events with perf record, and can be triggered
> >>> artificially with the script below:
> >>>
> >>> ----
> >>> #!/bin/sh
> >>> printf "REPRO: launching perf\n";
> >>> ./perf record -e software/config=9/ sleep 1 &
> >>> PERF_PID=$!;
> >>> sleep 0.002;
> >>> kill -2 $PERF_PID;
> >>> printf "REPRO: waiting for perf (%d) to exit...\n" "$PERF_PID";
> >>> wait $PERF_PID;
> >>> printf "REPRO: perf exited\n";
> >>> ----
> >>
> >> So, I run it here, without this patch, and get:
> >>
> >>   [root@zoo ~]# time ./repro.sh 
> >>   REPRO: launching perf
> >>   REPRO: waiting for perf (766) to exit...
> >>   [ perf record: Woken up 1 times to write data ]
> >>   [ perf record: Captured and wrote 0.015 MB perf.data ]
> >>   REPRO: perf exited
> >>   real	0m1.060s
> >>   user	0m0.018s
> >>   sys	0m0.037s
> > 
> > [...]
> > 
> >> What am I doing wrong? Trying to reproduce this before even looking at
> >> the patch :-)
> > 
> > I suspect you have a shinier computer than I do! ;)
> > 
> 
> I imagine you would also need to contrive not to write any synthesized MMAP
> or COMM events i.e. no access to /proc perhaps?

Taking a look through __cmd_record:

I'm not writing to a pipe, so nothing gets synthesized for attrs or tracepoints.

I'm not using aux trace, so nothing gets synthesized for that.

Running as a regular user I don't have synthesized events for the kernel mmap
or modules:

	WARNING: Kernel address maps (/proc/{kallsyms,modules}) are restricted,
	check /proc/sys/kernel/kptr_restrict.

	Samples in kernel functions may not be resolved if a suitable vmlinux
	file is not found in the buildid cache or in the vmlinux path.

	Samples in kernel modules won't be resolved at all.

	If some relocation was applied (e.g. kexec) symbols may be misresolved
	even with a suitable vmlinux or kallsyms file.

	Cannot read kernel map
	Couldn't record kernel reference relocation symbol
	Symbol resolution may be skewed if relocation was used (e.g. kexec).
	Check /proc/kallsyms permission or run as root.

I'm not running a guest, so I don't have any synthesized events for the guest
os.

__machine__synthesize_threads doesn't synthesize any task events
(target__has_task(target) is false at this point, as is
target__has_cpu(target)), because perf starts the workload later via
perf_evlist__start_workload.

So it looks like I shouldn't have any synthesized events. Have I missed
anything?

Thanks,
Mark.

  reply	other threads:[~2015-09-18  9:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-16 17:18 [PATCH] perf tools: session: avoid infinite loop Mark Rutland
2015-09-16 20:54 ` Arnaldo Carvalho de Melo
2015-09-17 15:41   ` Mark Rutland
2015-09-18  6:09     ` Adrian Hunter
2015-09-18  9:51       ` Mark Rutland [this message]
2015-09-18 10:55         ` Adrian Hunter
2015-09-18 13:37           ` Mark Rutland
2015-09-18 15:00             ` Arnaldo Carvalho de Melo
2015-09-18 15:18               ` Mark Rutland
2015-09-18 15:29                 ` Arnaldo Carvalho de Melo
2015-09-21 12:33                   ` Adrian Hunter
2015-09-23  8:42 ` [tip:perf/core] perf record: Avoid infinite loop at buildid processing with no samples tip-bot for Mark Rutland

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=20150918095112.GA21286@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.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