All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Zickus <dzickus@redhat.com>
To: Gaurav Jain <gjain@fb.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: Wed, 15 Jan 2014 09:27:27 -0500	[thread overview]
Message-ID: <20140115142727.GJ25953@redhat.com> (raw)
In-Reply-To: <CEFB09CC.2CAAA%gjain@fb.com>

On Tue, Jan 14, 2014 at 08:48:23PM +0000, Gaurav Jain wrote:
> 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.

Thanks for the improved problem description.   I see it led to a better
patch. :-)  That is why it is generally a good idea to describe the
problem you are trying to solve to see if others have a better solution.

Cheers,
Don

> 
> >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
> 

  parent reply	other threads:[~2014-01-15 14:27 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
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 [this message]
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=20140115142727.GJ25953@redhat.com \
    --to=dzickus@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=asharma@fb.com \
    --cc=gjain@fb.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.