From: Gaurav Jain <gjain@fb.com>
To: Don Zickus <dzickus@redhat.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>, Jiri Olsa <jolsa@redhat.com>,
Paul Mackerras <paulus@samba.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Arun Sharma <asharma@fb.com>
Subject: Re: [PATCH] perf tools: Synthesize anon MMAP records on the heap
Date: Tue, 14 Jan 2014 20:48:23 +0000 [thread overview]
Message-ID: <CEFB09CC.2CAAA%gjain@fb.com> (raw)
In-Reply-To: <20140113165441.GB25953@redhat.com>
On 1/13/14, 11:54 AM, "Don Zickus" <dzickus@redhat.com> wrote:
>On Sat, Jan 11, 2014 at 08:32:14PM -0800, Gaurav Jain wrote:
>> Anon records usually do not have the 'execname' entry. However if they
>>are on
>> the heap, the execname shows up as '[heap]'. The fix considers any
>>executable
>> entries in the map that do not have a name or are on the heap as anon
>>records
>> and sets the name to '//anon'.
>>
>> This fixes JIT profiling for records on the heap.
>
>I guess I don't understand the need for this fix. It seems breaking out
>//anon vs. [heap] would be useful. Your patch is saying otherwise. Can
>give a description of the problem you are trying to solve?
Thank you for looking at the patch.
We generate a perf map file which includes certain JIT¹ed functions that
show up as [heap] entries. As a result, I included the executable heap
entries as anon pages so that it would be handled in
util/map.c:map__new(). The alternative would be to handle heap entries in
map__new() directly, however I wasn¹t sure if this would break something
as it seems that heap and stack entries are expected to fail all
map__find_* functions. Thus I considered executable heap entries as
//anon, but perhaps there is a better way.
>Also style issue below..
>
>>
>> Signed-off-by: Gaurav Jain <gjain@fb.com>
>> Cc: Ingo Molnar <mingo@kernel.org>
>> Cc: Jiri Olsa <jolsa@redhat.com>
>> Cc: Paul Mackerras <paulus@samba.org>
>> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
>> Cc: Don Zickus <dzickus@redhat.com>
>> Cc: Arun Sharma <asharma@fb.com>
>> ---
>> tools/perf/util/event.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
>> index bb788c1..ae9c55b 100644
>> --- a/tools/perf/util/event.c
>> +++ b/tools/perf/util/event.c
>> @@ -224,10 +224,9 @@ static int
>>perf_event__synthesize_mmap_events(struct perf_tool *tool,
>> continue;
>>
>> event->header.misc |= PERF_RECORD_MISC_MMAP_DATA;
>> - }
>> -
>> - if (!strcmp(execname, ""))
>> + } if (!strcmp(execname, "") || !strcmp(execname, "[heap]")) {
>
>The '} if' part should seperate the 'if' on to its own line (unless you
>meant an 'else' in there).
Bah yes, I intended 'else if'. I apologize for that. Does the fact that I
filtered anon entries to only those marked as executable break the
existing behavior?
Thanks,
Gaurav
next prev parent reply other threads:[~2014-01-14 20:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-12 4:32 [PATCH] perf tools: Synthesize anon MMAP records on the heap Gaurav Jain
2014-01-13 8:59 ` Namhyung Kim
2014-01-13 16:54 ` Don Zickus
2014-01-14 20:48 ` Gaurav Jain [this message]
2014-01-15 5:46 ` Namhyung Kim
2014-01-15 6:44 ` Gaurav Jain
2014-01-16 1:01 ` Namhyung Kim
2014-01-16 2:40 ` Gaurav Jain
2014-01-15 14:27 ` Don Zickus
2014-01-16 1:03 ` Namhyung Kim
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=CEFB09CC.2CAAA%gjain@fb.com \
--to=gjain@fb.com \
--cc=a.p.zijlstra@chello.nl \
--cc=asharma@fb.com \
--cc=dzickus@redhat.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulus@samba.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.