From: Andi Kleen <andi@firstfloor.org>
To: Stephane Eranian <eranian@google.com>
Cc: Kan Liang <kan.liang@intel.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
Andi Kleen <andi@firstfloor.org>
Subject: Re: [PATCH V5 3/6] perf, x86: large PEBS interrupt threshold
Date: Mon, 2 Mar 2015 18:59:28 +0100 [thread overview]
Message-ID: <20150302175928.GH823@two.firstfloor.org> (raw)
In-Reply-To: <CABPqkBSwuNpUJGTtW_2q7MRrueAH+9UN2f_fFvJDR4AzWG5APQ@mail.gmail.com>
> At more reasonable periods, the benefit seems to vanish. I don't quite know
> of a scenario where one would absolutely need very small period. This is
> about statistical sampling and not tracing.
In workloads with small irregular events (e.g. irregularly
space event handlers that run for less than a milli-second) a small
period is the only reliable way to catch them.
You're right the mode is not very useful for anything
that runs the same code continuously.
However irregular scenarios are becoming more and more
important. For example this is useful for characterizing
complex GUI applications.
> I believe that you need to know exactly what you are doing, i.e., what you
> are measuring for this improvement to make a difference and yet provide
> useful data. I believe in system-wide mode, the benefit vanishes quickly
> because you may not know in advance what you are measuring. The
> key problem is the lack of timestamp which help order the MMAP records
> vs. sample records. I tried with my recently released Jitted code patch
> series and sure enough with the --no-time, you cannot correlate samples
> to symbols in the jitted code anymore. This is a case where you need
> the timestamps to synchronize user level sampling data (obtained from
> the jit compiler) with perf samples. Unless I know I am measuring jitted
> code, I would not be able to use the PEBS buffer improvements without
> losing symbolization capabilities.
This is only when the JIT regularly reuses virtual address space.
If it mostly uses new addresses there is no issue, as the
mappings are unique. I believe JITs rarely reuse.
> Overall, I think the patch is only useful to a small set of monitoring scenarios
> and for people using "extreme" sampling periods. It requires the user to be
> aware of the behavior of the monitoring app (because of the no-timestamp
> requirement).
Yes right now with all the limitations you need to know
what you're doing. However it's still useful for experts.
-Andi
next prev parent reply other threads:[~2015-03-02 17:59 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-23 14:25 [PATCH V5 0/6] large PEBS interrupt threshold Kan Liang
2015-02-23 14:25 ` [PATCH V5 1/6] perf, x86: use the PEBS auto reload mechanism when possible Kan Liang
2015-03-30 12:06 ` Peter Zijlstra
2015-03-30 14:02 ` Peter Zijlstra
2015-02-23 14:25 ` [PATCH V5 2/6] perf, x86: introduce setup_pebs_sample_data() Kan Liang
2015-02-23 14:25 ` [PATCH V5 3/6] perf, x86: large PEBS interrupt threshold Kan Liang
2015-03-02 17:08 ` Stephane Eranian
2015-03-02 17:59 ` Andi Kleen [this message]
2015-03-02 18:07 ` Stephane Eranian
2015-03-30 13:54 ` Peter Zijlstra
2015-02-23 14:25 ` [PATCH V5 4/6] perf, x86: handle multiple records in PEBS buffer Kan Liang
2015-03-30 13:45 ` Peter Zijlstra
2015-03-30 17:19 ` Liang, Kan
2015-03-30 17:25 ` Andi Kleen
2015-03-30 17:43 ` Liang, Kan
2015-03-30 17:45 ` Andi Kleen
2015-03-30 20:07 ` Peter Zijlstra
2015-03-30 20:11 ` Andi Kleen
2015-03-30 21:24 ` Peter Zijlstra
2015-03-30 21:53 ` Andi Kleen
2015-02-23 14:25 ` [PATCH V5 5/6] perf, x86: drain PEBS buffer during context switch Kan Liang
2015-03-30 13:50 ` Peter Zijlstra
2015-02-23 14:25 ` [PATCH V5 6/6] perf, x86: enlarge PEBS buffer Kan Liang
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=20150302175928.GH823@two.firstfloor.org \
--to=andi@firstfloor.org \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@infradead.org \
--cc=eranian@google.com \
--cc=kan.liang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@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