All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
To: Don Zickus <dzickus@redhat.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	jolsa@redhat.com, eranian@google.com
Subject: Re: [PATCH 3/3] perf: fix synthesizing mmaps for threads
Date: Wed, 26 Feb 2014 11:17:26 -0300	[thread overview]
Message-ID: <20140226141726.GA7552@ghostprotocols.net> (raw)
In-Reply-To: <1393386227-149412-4-git-send-email-dzickus@redhat.com>

Em Tue, Feb 25, 2014 at 10:43:47PM -0500, Don Zickus escreveu:
> Currently if a process creates a bunch of threads using pthread_create
> and then perf is run in system_wide mode, the mmaps for those threads
> are not captured with a synthesized mmap event.
> 
> The reason is those threads are not visible when walking the /proc/
> directory looking for /proc/<pid>/maps files.  Instead they are discovered
> using the /proc/<pid>/tasks file (which the synthesized comm event uses).
> 
> This causes problems when a program is trying to map a data address to a
> tid.  Because the tid has no maps, the event is dropped.  Changing the program
> to look up using the pid instead of the tid, finds the correct maps but creates
> ugly hacks in the program to carry the correct tid around.
> 
> Fix this by synthesizing mmap events for each tid found in the /proc/<pid>/tasks
> file.

This seems to cover two problems, the first is for mmap/mmap2 event
processing to lookup pid/tid instead of pid/pid, the other one is to
iterate thru /proc/pid/tasks/, so this needes spliting up.

Now looking at the /tasks/ part...
 
> This may not be entirely clean but it seems to work.
> 
> Signed-off-by: Don Zickus <dzickus@redhat.com>
> ---
>  tools/perf/util/event.c   | 15 +++++++++++----
>  tools/perf/util/machine.c |  4 ++--
>  2 files changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
> index 086c7c8..09c53bb 100644
> --- a/tools/perf/util/event.c
> +++ b/tools/perf/util/event.c
> @@ -93,10 +93,13 @@ static pid_t perf_event__get_comm_tgid(pid_t pid, char *comm, size_t len)
>  }
>  
>  static pid_t perf_event__synthesize_comm(struct perf_tool *tool,
> -					 union perf_event *event, pid_t pid,
> +					 union perf_event *event,
> +					 union perf_event *mmap_event,
> +					 pid_t pid,
>  					 int full,
>  					 perf_event__handler_t process,
> -					 struct machine *machine)
> +					 struct machine *machine,
> +					 bool mmap_data)
>  {
>  	char filename[PATH_MAX];
>  	size_t size;
> @@ -168,6 +171,10 @@ static pid_t perf_event__synthesize_comm(struct perf_tool *tool,
>  			tgid = -1;
>  			break;
>  		}
> +
> +		/* process the thread's maps too */
> +		perf_event__synthesize_mmap_events(tool, mmap_event, pid, tgid,
> +						  process, machine, mmap_data);
>  	}
>  
>  	closedir(tasks);
> @@ -331,8 +338,8 @@ static int __event__synthesize_thread(union perf_event *comm_event,
>  				      struct perf_tool *tool,
>  				      struct machine *machine, bool mmap_data)
>  {
> -	pid_t tgid = perf_event__synthesize_comm(tool, comm_event, pid, full,
> -						 process, machine);
> +	pid_t tgid = perf_event__synthesize_comm(tool, comm_event, mmap_event, pid,
> +						 full, process, machine, mmap_data);
>  	if (tgid == -1)
>  		return -1;
>  	return perf_event__synthesize_mmap_events(tool, mmap_event, pid, tgid,
> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> index 813e94e..eb26544 100644
> --- a/tools/perf/util/machine.c
> +++ b/tools/perf/util/machine.c
> @@ -1026,7 +1026,7 @@ int machine__process_mmap2_event(struct machine *machine,
>  	}
>  
>  	thread = machine__findnew_thread(machine, event->mmap2.pid,
> -					event->mmap2.pid);
> +					event->mmap2.tid);
>  	if (thread == NULL)
>  		goto out_problem;
>  
> @@ -1074,7 +1074,7 @@ int machine__process_mmap_event(struct machine *machine, union perf_event *event
>  	}
>  
>  	thread = machine__findnew_thread(machine, event->mmap.pid,
> -					 event->mmap.pid);
> +					 event->mmap.tid);
>  	if (thread == NULL)
>  		goto out_problem;
>  
> -- 
> 1.7.11.7

  reply	other threads:[~2014-02-26 14:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-26  3:43 [PATCH 0/3] perf: misc fixes Don Zickus
2014-02-26  3:43 ` [PATCH 1/3] perf, machine: Use map as success in ip__resolve_ams Don Zickus
2014-03-11 10:16   ` [tip:perf/urgent] perf " tip-bot for Don Zickus
2014-02-26  3:43 ` [PATCH 2/3] perf, session: Change header.misc dump from decimal to hex Don Zickus
2014-03-18  8:30   ` [tip:perf/core] perf " tip-bot for Don Zickus
2014-02-26  3:43 ` [PATCH 3/3] perf: fix synthesizing mmaps for threads Don Zickus
2014-02-26 14:17   ` Arnaldo Carvalho de Melo [this message]
2014-02-26 14:32     ` Arnaldo Carvalho de Melo
2014-02-26 14:44     ` Don Zickus

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=20140226141726.GA7552@ghostprotocols.net \
    --to=acme@ghostprotocols.net \
    --cc=dzickus@redhat.com \
    --cc=eranian@google.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.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 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.