All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Stephane Eranian <eranian@google.com>
Cc: linux-kernel@vger.kernel.org, acme@redhat.com,
	peterz@infradead.org, mingo@elte.hu, ak@linux.intel.com,
	jolsa@redhat.com, namhyung@kernel.org, cel@us.ibm.com,
	sukadev@linux.vnet.ibm.com, sonnyrao@chromium.org,
	johnmccutchan@google.com, dsahern@gmail.com,
	adrian.hunter@intel.com, pawell.moll@arm.com,
	Pekka Enberg <penberg@iki.fi>
Subject: Re: [PATCH v2 0/4] perf: add support for profiling jitted code
Date: Wed, 18 Feb 2015 18:31:45 +0100	[thread overview]
Message-ID: <20150218173145.GB31174@gmail.com> (raw)
In-Reply-To: <1424280109-9801-1-git-send-email-eranian@google.com>


* Stephane Eranian <eranian@google.com> wrote:

> The current support only works when the runtime is 
> monitored from start to finish: perf record java 
> --agenpath:libpfmjvmti.so my_class.

Could we add '--agenpath:libpfmjvmti.so' automatically if a 
binary called 'java' is recorded?

( With a --nojavajit flag to not do that, should someone
  feel like having a 'java' executable that doesn't accept
  the --agenpath flag, or so? Assuming the major JVMs 
  accept the --agenpath flag. )

> Once the run is completed, the jitdump file needs to be 
> injected into the perf.data file. This is accomplished by 
> using the perf inject command. This will also generate an 
> ELF image for each jitted function. The inject MMAP 
> records will point to those ELF images. The reasoning 
> behind using ELF images is that it makes processing for 
> perf report and annotate automatic and transparent. It 
> also makes it easier to package and analyze on a remote 
> machine.

So it would be nice if this part was automatic, i.e. if I 
could just profile a java run with the regular perf 
profiling flow.

> The reporting is unchanged, simply invoke perf report or 
> perf annotate on the modified perf.data file. The jitted 
> code will appear symbolized and the assembly view will 
> display the instruction level profile!
> 
> As an added bonus, the series includes support for 
> demangling function signature from OpenJDK.

Cool!

> Furthermore, we believe there is a way to skip the perf 
> inject phase and have perf report/annotate directly 
> inject the MMAP records on the fly during processing of 
> the perf.data file. Perf report would also generate the 
> ELF files if necessary. Such optimization, would make 
> using this extension seamless in system-wide mode and 
> larger environments. This will be added in a later update 
> as well.

I think angling for seemless operation is really important.

> To use the new feature:
>   - compile and install the perf_posix_clock.ko module:
>     - make modules (say M to PERF_CLOCK config option)
>     - make modules_install;
>     - modprobe perf_posix_clock
>     - dmesg should say: perf_clock clock registered
>   - compile perf
>   - cd tools/perf/jvmti; make; install wherever is appropriate

Will 'make -C tools/perf install' DTRT, or is the last step 
needed separately?

Thanks,

	Ingo

      parent reply	other threads:[~2015-02-18 17:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-18 17:21 [PATCH v2 0/4] perf: add support for profiling jitted code Stephane Eranian
2015-02-18 17:21 ` [PATCH v2 1/4] perf tools: add Java demangling support Stephane Eranian
2015-02-18 17:21 ` [PATCH v2 2/4] perf inject: add jitdump mmap injection support Stephane Eranian
2015-02-18 17:21 ` [PATCH v2 3/4] perf tools: add JVMTI agent library Stephane Eranian
2015-02-18 17:21 ` [PATCH v2 4/4] clock: add perf_clock posix clock Stephane Eranian
2015-02-18 17:53   ` Ingo Molnar
2015-02-18 18:00   ` John Stultz
2015-02-18 18:10     ` Stephane Eranian
2015-02-18 18:15       ` John Stultz
2015-02-18 18:11     ` David Ahern
2015-02-18 18:18       ` John Stultz
2015-02-18 18:21         ` Stephane Eranian
2015-02-18 18:22         ` Ingo Molnar
2015-02-18 19:00   ` Paul Bolle
2015-02-18 19:12   ` Paul Bolle
2015-02-18 17:31 ` Ingo Molnar [this message]

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=20150218173145.GB31174@gmail.com \
    --to=mingo@kernel.org \
    --cc=acme@redhat.com \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=cel@us.ibm.com \
    --cc=dsahern@gmail.com \
    --cc=eranian@google.com \
    --cc=johnmccutchan@google.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=namhyung@kernel.org \
    --cc=pawell.moll@arm.com \
    --cc=penberg@iki.fi \
    --cc=peterz@infradead.org \
    --cc=sonnyrao@chromium.org \
    --cc=sukadev@linux.vnet.ibm.com \
    /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.