public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox