Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756057AbbFSXS5 (ORCPT ); Fri, 19 Jun 2015 19:18:57 -0400 Received: from terminus.zytor.com ([198.137.202.10]:52832 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754980AbbFSXSr (ORCPT ); Fri, 19 Jun 2015 19:18:47 -0400 Date: Fri, 19 Jun 2015 16:18:20 -0700 From: tip-bot for Kan Liang Message-ID: Cc: tglx@linutronix.de, mingo@kernel.org, acme@redhat.com, dsahern@gmail.com, linux-kernel@vger.kernel.org, andi@firstfloor.org, ying.huang@intel.com, kan.liang@intel.com, hpa@zytor.com Reply-To: hpa@zytor.com, kan.liang@intel.com, ying.huang@intel.com, dsahern@gmail.com, acme@redhat.com, linux-kernel@vger.kernel.org, andi@firstfloor.org, tglx@linutronix.de, mingo@kernel.org In-Reply-To: <1434549071-25611-1-git-send-email-kan.liang@intel.com> References: <1434549071-25611-1-git-send-email-kan.liang@intel.com> To: linux-tip-commits@vger.kernel.org Subject: [tip:perf/core] perf tools: Add time out to force stop proc map processing Git-Commit-ID: 930e6fcd2bcce9bcd9d4aa7e755678d33f3fe6f4 X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5529 Lines: 158 Commit-ID: 930e6fcd2bcce9bcd9d4aa7e755678d33f3fe6f4 Gitweb: http://git.kernel.org/tip/930e6fcd2bcce9bcd9d4aa7e755678d33f3fe6f4 Author: Kan Liang AuthorDate: Wed, 17 Jun 2015 09:51:10 -0400 Committer: Arnaldo Carvalho de Melo CommitDate: Fri, 19 Jun 2015 18:20:15 -0300 perf tools: Add time out to force stop proc map processing System wide sampling like 'perf top' or 'perf record -a' read all threads /proc/xxx/maps before sampling. If there are any threads which generating a keeping growing huge maps, perf will do infinite loop during synthesizing. Nothing will be sampled. This patch fixes this issue by adding per-thread timeout to force stop this kind of endless proc map processing. PERF_RECORD_MISC_PROC_MAP_PARSE_TIME_OUT is introduced to indicate that the mmap record are truncated by time out. User will get warning notification when truncated mmap records are detected. Reported-by: Ying Huang Signed-off-by: Kan Liang Cc: Andi Kleen Cc: David Ahern Cc: Ying Huang Link: http://lkml.kernel.org/r/1434549071-25611-1-git-send-email-kan.liang@intel.com Signed-off-by: Arnaldo Carvalho de Melo --- include/uapi/linux/perf_event.h | 4 ++++ tools/perf/util/event.c | 18 ++++++++++++++++++ tools/perf/util/event.h | 1 + tools/perf/util/session.c | 11 +++++++++++ 4 files changed, 34 insertions(+) diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h index 613ed9a..d97f84c 100644 --- a/include/uapi/linux/perf_event.h +++ b/include/uapi/linux/perf_event.h @@ -566,6 +566,10 @@ struct perf_event_mmap_page { #define PERF_RECORD_MISC_GUEST_USER (5 << 0) /* + * Indicates that /proc/PID/maps parsing are truncated by time out. + */ +#define PERF_RECORD_MISC_PROC_MAP_PARSE_TIMEOUT (1 << 12) +/* * PERF_RECORD_MISC_MMAP_DATA and PERF_RECORD_MISC_COMM_EXEC are used on * different events so can reuse the same bit position. */ diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c index 793b150..416ba80 100644 --- a/tools/perf/util/event.c +++ b/tools/perf/util/event.c @@ -213,6 +213,8 @@ static int perf_event__synthesize_fork(struct perf_tool *tool, return 0; } +#define PROC_MAP_PARSE_TIMEOUT (500 * 1000000ULL) + int perf_event__synthesize_mmap_events(struct perf_tool *tool, union perf_event *event, pid_t pid, pid_t tgid, @@ -222,6 +224,8 @@ int perf_event__synthesize_mmap_events(struct perf_tool *tool, { char filename[PATH_MAX]; FILE *fp; + unsigned long long t; + bool truncation = false; int rc = 0; if (machine__is_default_guest(machine)) @@ -240,6 +244,7 @@ int perf_event__synthesize_mmap_events(struct perf_tool *tool, } event->header.type = PERF_RECORD_MMAP2; + t = rdclock(); while (1) { char bf[BUFSIZ]; @@ -253,6 +258,12 @@ int perf_event__synthesize_mmap_events(struct perf_tool *tool, if (fgets(bf, sizeof(bf), fp) == NULL) break; + if ((rdclock() - t) > PROC_MAP_PARSE_TIMEOUT) { + pr_warning("Reading %s time out.\n", filename); + truncation = true; + goto out; + } + /* ensure null termination since stack will be reused. */ strcpy(execname, ""); @@ -301,6 +312,10 @@ int perf_event__synthesize_mmap_events(struct perf_tool *tool, event->header.misc |= PERF_RECORD_MISC_MMAP_DATA; } +out: + if (truncation) + event->header.misc |= PERF_RECORD_MISC_PROC_MAP_PARSE_TIMEOUT; + if (!strcmp(execname, "")) strcpy(execname, anonstr); @@ -319,6 +334,9 @@ int perf_event__synthesize_mmap_events(struct perf_tool *tool, rc = -1; break; } + + if (truncation) + break; } fclose(fp); diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h index 5dc51ad..39868f5 100644 --- a/tools/perf/util/event.h +++ b/tools/perf/util/event.h @@ -265,6 +265,7 @@ struct events_stats { u32 nr_unknown_id; u32 nr_unprocessable_samples; u32 nr_auxtrace_errors[PERF_AUXTRACE_ERROR_MAX]; + u32 nr_proc_map_timeout; }; struct attr_event { diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c index c371336..2d882fd 100644 --- a/tools/perf/util/session.c +++ b/tools/perf/util/session.c @@ -1064,6 +1064,8 @@ static int machines__deliver_event(struct machines *machines, case PERF_RECORD_MMAP: return tool->mmap(tool, event, sample, machine); case PERF_RECORD_MMAP2: + if (event->header.misc & PERF_RECORD_MISC_PROC_MAP_PARSE_TIMEOUT) + ++evlist->stats.nr_proc_map_timeout; return tool->mmap2(tool, event, sample, machine); case PERF_RECORD_COMM: return tool->comm(tool, event, sample, machine); @@ -1360,6 +1362,15 @@ static void perf_session__warn_about_errors(const struct perf_session *session) ui__warning("%u out of order events recorded.\n", oe->nr_unordered_events); events_stats__auxtrace_error_warn(stats); + + if (stats->nr_proc_map_timeout != 0) { + ui__warning("%d map information files for pre-existing threads were\n" + "not processed, if there are samples for addresses they\n" + "will not be resolved, you may find out which are these\n" + "threads by running with -v and redirecting the output\n" + "to a file.\n", + stats->nr_proc_map_timeout); + } } static int perf_session__flush_thread_stack(struct thread *thread, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/