All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] perf: Fallback to MAP__FUNCTION if daddr maps are NULL
@ 2014-08-21  3:25 Don Zickus
  2014-08-21  7:04 ` Jiri Olsa
  2014-08-24 14:59 ` [tip:perf/core] perf machine: " tip-bot for Don Zickus
  0 siblings, 2 replies; 4+ messages in thread
From: Don Zickus @ 2014-08-21  3:25 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo, Jiri Olsa; +Cc: LKML, eranian, jmario, Don Zickus

As we run "perf c2c" on more applications, we noticed we're missing significant
samples from a common customer's application.  Looking at the
/proc/<pid>/maps file for the app, we see "rwxs" and "rwxp" permissions on many
of the shared memory & heap regions, and on all the thread stacks.

Because those regions have the "x" bit set, perf marks them with a MAP_FUNCTION
type.  Hence ip_resolve_data() never finds load or store events coming from
them.

We fixed this by re-calling thread__find_addr_location with MAP__FUNCTION in
the case where map is NULL as a last ditch effort to map the sample before
giving up and dropping it.

Reported-by: Joe Mario <jmario@redhat.com>
Tested-by: Joe Mario <jmario@redhat.com>
Signed-off-by: Don Zickus <dzickus@redhat.com>
---
 tools/perf/util/machine.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 0e5fea9..e62bd87 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1241,6 +1241,16 @@ static void ip__resolve_data(struct machine *machine, struct thread *thread,
 
 	thread__find_addr_location(thread, machine, m, MAP__VARIABLE, addr,
 				   &al);
+	if (al.map == NULL) {
+		/*
+		 * some shared data regions have execute bit set which puts
+		 * their mapping in the MAP__FUNCTION type array.
+		 * Check there as a fallback option before dropping the sample.
+		 */
+		thread__find_addr_location(thread, machine, m, MAP__FUNCTION, addr,
+					   &al);
+	}
+
 	ams->addr = addr;
 	ams->al_addr = al.addr;
 	ams->sym = al.sym;
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] perf: Fallback to MAP__FUNCTION if daddr maps are NULL
  2014-08-21  3:25 [PATCH] perf: Fallback to MAP__FUNCTION if daddr maps are NULL Don Zickus
@ 2014-08-21  7:04 ` Jiri Olsa
  2014-08-21 15:48   ` Arnaldo Carvalho de Melo
  2014-08-24 14:59 ` [tip:perf/core] perf machine: " tip-bot for Don Zickus
  1 sibling, 1 reply; 4+ messages in thread
From: Jiri Olsa @ 2014-08-21  7:04 UTC (permalink / raw)
  To: Don Zickus; +Cc: Arnaldo Carvalho de Melo, LKML, eranian, jmario

On Wed, Aug 20, 2014 at 11:25:11PM -0400, Don Zickus wrote:
> As we run "perf c2c" on more applications, we noticed we're missing significant
> samples from a common customer's application.  Looking at the
> /proc/<pid>/maps file for the app, we see "rwxs" and "rwxp" permissions on many
> of the shared memory & heap regions, and on all the thread stacks.
> 
> Because those regions have the "x" bit set, perf marks them with a MAP_FUNCTION
> type.  Hence ip_resolve_data() never finds load or store events coming from
> them.
> 
> We fixed this by re-calling thread__find_addr_location with MAP__FUNCTION in
> the case where map is NULL as a last ditch effort to map the sample before
> giving up and dropping it.
> 
> Reported-by: Joe Mario <jmario@redhat.com>
> Tested-by: Joe Mario <jmario@redhat.com>
> Signed-off-by: Don Zickus <dzickus@redhat.com>

Acked-by: Jiri Olsa <jolsa@kernel.org>

thanks,
jirka

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] perf: Fallback to MAP__FUNCTION if daddr maps are NULL
  2014-08-21  7:04 ` Jiri Olsa
@ 2014-08-21 15:48   ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 4+ messages in thread
From: Arnaldo Carvalho de Melo @ 2014-08-21 15:48 UTC (permalink / raw)
  To: Jiri Olsa; +Cc: Don Zickus, LKML, eranian, jmario

Em Thu, Aug 21, 2014 at 09:04:51AM +0200, Jiri Olsa escreveu:
> On Wed, Aug 20, 2014 at 11:25:11PM -0400, Don Zickus wrote:
> > As we run "perf c2c" on more applications, we noticed we're missing significant
> > samples from a common customer's application.  Looking at the
> > /proc/<pid>/maps file for the app, we see "rwxs" and "rwxp" permissions on many
> > of the shared memory & heap regions, and on all the thread stacks.
> > 
> > Because those regions have the "x" bit set, perf marks them with a MAP_FUNCTION
> > type.  Hence ip_resolve_data() never finds load or store events coming from
> > them.
> > 
> > We fixed this by re-calling thread__find_addr_location with MAP__FUNCTION in
> > the case where map is NULL as a last ditch effort to map the sample before
> > giving up and dropping it.
> > 
> > Reported-by: Joe Mario <jmario@redhat.com>
> > Tested-by: Joe Mario <jmario@redhat.com>
> > Signed-off-by: Don Zickus <dzickus@redhat.com>
> 
> Acked-by: Jiri Olsa <jolsa@kernel.org>

Thanks, applied.

- Arnaldo

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [tip:perf/core] perf machine: Fallback to MAP__FUNCTION if daddr maps are NULL
  2014-08-21  3:25 [PATCH] perf: Fallback to MAP__FUNCTION if daddr maps are NULL Don Zickus
  2014-08-21  7:04 ` Jiri Olsa
@ 2014-08-24 14:59 ` tip-bot for Don Zickus
  1 sibling, 0 replies; 4+ messages in thread
From: tip-bot for Don Zickus @ 2014-08-24 14:59 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: acme, linux-kernel, eranian, hpa, mingo, jolsa, jmario, jolsa,
	tglx, dzickus

Commit-ID:  06b2afc0b9a26e7673856a24ab57bfb307dad394
Gitweb:     http://git.kernel.org/tip/06b2afc0b9a26e7673856a24ab57bfb307dad394
Author:     Don Zickus <dzickus@redhat.com>
AuthorDate: Wed, 20 Aug 2014 23:25:11 -0400
Committer:  Arnaldo Carvalho de Melo <acme@redhat.com>
CommitDate: Fri, 22 Aug 2014 13:12:13 -0300

perf machine: Fallback to MAP__FUNCTION if daddr maps are NULL

As we run "perf c2c" on more applications, we noticed we're missing
significant samples from a common customer's application.  Looking at
the /proc/<pid>/maps file for the app, we see "rwxs" and "rwxp"
permissions on many of the shared memory & heap regions, and on all the
thread stacks.

Because those regions have the "x" bit set, perf marks them with a
MAP_FUNCTION type.  Hence ip_resolve_data() never finds load or store
events coming from them.

We fixed this by re-calling thread__find_addr_location with
MAP__FUNCTION in the case where map is NULL as a last ditch effort to
map the sample before giving up and dropping it.

Reported-by: Joe Mario <jmario@redhat.com>
Tested-by: Joe Mario <jmario@redhat.com>
Signed-off-by: Don Zickus <dzickus@redhat.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Joe Mario <jmario@redhat.com>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/1408591511-57884-1-git-send-email-dzickus@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 tools/perf/util/machine.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index e00daf0..b2ec38b 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1314,6 +1314,16 @@ static void ip__resolve_data(struct machine *machine, struct thread *thread,
 
 	thread__find_addr_location(thread, machine, m, MAP__VARIABLE, addr,
 				   &al);
+	if (al.map == NULL) {
+		/*
+		 * some shared data regions have execute bit set which puts
+		 * their mapping in the MAP__FUNCTION type array.
+		 * Check there as a fallback option before dropping the sample.
+		 */
+		thread__find_addr_location(thread, machine, m, MAP__FUNCTION, addr,
+					   &al);
+	}
+
 	ams->addr = addr;
 	ams->al_addr = al.addr;
 	ams->sym = al.sym;

^ permalink raw reply related	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-08-24 14:59 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-21  3:25 [PATCH] perf: Fallback to MAP__FUNCTION if daddr maps are NULL Don Zickus
2014-08-21  7:04 ` Jiri Olsa
2014-08-21 15:48   ` Arnaldo Carvalho de Melo
2014-08-24 14:59 ` [tip:perf/core] perf machine: " tip-bot for Don Zickus

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.