From: Don Zickus <dzickus@redhat.com>
To: Stephane Eranian <eranian@google.com>
Cc: linux-kernel@vger.kernel.org, acme@redhat.com, jolsa@redhat.com,
peterz@infradead.org, mingo@elte.hu, namhyung@kernel.org,
dsahern@gmail.com
Subject: Re: [PATCH] perf tools: fix processing of pid/tid for mmap records
Date: Tue, 22 Apr 2014 15:40:31 -0400 [thread overview]
Message-ID: <20140422194031.GM8488@redhat.com> (raw)
In-Reply-To: <20140421160655.GA4201@quad>
On Mon, Apr 21, 2014 at 06:06:55PM +0200, Stephane Eranian wrote:
> perf tools: fix processing of pid/tid for mmap records
>
> Mmaps are global to a process (always). Processing them
> per-thread was causing some serious issues in case mmaps
> would overlap. The overlap fixups would only occur in the
> context of the thread which generated the overlapping
> mmap. But that was cause issues later on when a sample
> from another thread would fall into that overlapping
> mmap.
eh? You are basically reverting my patch for a similar problem. :-)
I was running a large multi-threading program (specjbb) and the threads
were not being seperated into their own map'd areas. So either I had to
lump all threads in to the same pid space or make the change you are
reverting.
The problem I had with the double pid (as you propose), I would later look
up samples based on pid/tid and there would be _no_ map available because
it was created as a pid/pid pair. As a result, our c2c program would drop
thousands of samples on the floor (because there was no mapping for the
data address to get the major/minor/inode info).
Now I modified our c2c program to lookup samples as pid/pid but now the
maps lost tid info, and I had to hack around that by carrying the tid info
in a private struct.
Hopefully Jiri's thread work using pointers will solve both our problems.
:-) But I can't ack your patch because it will break my work :-(
Cheers,
Don
>
> The solution to the problem is to handle ALL mmaps as
> occurring in the master thread (pid = tid) and then to
> lookup for thread map using pid as the tid argument.
> This is how samples are looking up for the thread map
> already (notice pid passed twice):
>
> int perf_event__preprocess_sample(const union perf_event *event,
> struct machine *machine,
> struct addr_location *al,
> struct perf_sample *sample)
> {
> struct thread *thread = machine__findnew_thread(machine, sample->pid,
> sample->pid);
> }
>
> Without this fix, some samples in overlapping regions
> may not be symbolized.
>
> Signed-off-by: Stephane Eranian <eranian@google.com>
>
> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> index a53cd0b..43cdc0a 100644
> --- a/tools/perf/util/machine.c
> +++ b/tools/perf/util/machine.c
> @@ -1025,9 +1025,9 @@ int machine__process_mmap2_event(struct machine *machine,
> goto out_problem;
> return 0;
> }
> -
> + /* only look by pid for mmap events */
> thread = machine__findnew_thread(machine, event->mmap2.pid,
> - event->mmap2.tid);
> + event->mmap2.pid);
> if (thread == NULL)
> goto out_problem;
>
> @@ -1073,9 +1073,9 @@ int machine__process_mmap_event(struct machine *machine, union perf_event *event
> goto out_problem;
> return 0;
> }
> -
> + /* only look by pid for mmap events */
> thread = machine__findnew_thread(machine, event->mmap.pid,
> - event->mmap.tid);
> + event->mmap.pid);
> if (thread == NULL)
> goto out_problem;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2014-04-22 19:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-21 16:06 [PATCH] perf tools: fix processing of pid/tid for mmap records Stephane Eranian
2014-04-22 13:32 ` Jiri Olsa
2014-04-22 13:37 ` Stephane Eranian
2014-04-22 19:40 ` Don Zickus [this message]
2014-04-22 19:50 ` Stephane Eranian
2014-04-22 20:45 ` Don Zickus
2014-04-23 12:52 ` Stephane Eranian
2014-04-23 13:30 ` Don Zickus
2014-04-23 15:06 ` Stephane Eranian
2014-04-23 15:42 ` Jiri Olsa
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=20140422194031.GM8488@redhat.com \
--to=dzickus@redhat.com \
--cc=acme@redhat.com \
--cc=dsahern@gmail.com \
--cc=eranian@google.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=namhyung@kernel.org \
--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 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.