public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kan Liang <kan.liang@intel.com>
To: a.p.zijlstra@chello.nl, linux-kernel@vger.kernel.org
Cc: mingo@kernel.org, acme@infradead.org, eranian@google.com,
	andi@firstfloor.org, Kan Liang <kan.liang@intel.com>
Subject: [PATCH V6 0/6] large PEBS interrupt threshold
Date: Thu,  9 Apr 2015 12:37:40 -0400	[thread overview]
Message-ID: <1428597466-8154-1-git-send-email-kan.liang@intel.com> (raw)

This patch series implements large PEBS interrupt threshold.
Currently, the PEBS threshold is forced to set to one. A larger PEBS
interrupt threshold can significantly reduce the sampling overhead
especially for frequently occurring events
(like cycles or branches or load/stores) with small sampling period.
For example, perf record cycles event when running kernbench
with 10003 sampling period. The Elapsed Time reduced from 32.7 seconds
to 16.5 seconds, which is 2X faster.
For more details, please refer to patch 3's description.

Limitations:
 - It can not supply a callgraph.
 - It requires setting a fixed period.
 - It cannot supply a time stamp.
 - To supply a TID it requires flushing on context switch.
If the above requirement doesn't apply, the threshold will set to one.

Collisions:
When PEBS events happen near to each other, the records for the events
can be collapsed into a single one, and it's not possible to
reconstruct. When collision happens, we drop the PEBS record.
Actually, collisions are extremely rare as long as different events
are used. We once tested the worst case with four frequently occurring
events (cycles:p,instructions:p,branches:p,mem-stores:p).
The collisions rate is only 0.34%.
The only way you can get a lot of collision is when you count the same
thing multiple times. But it is not a useful configuration.
For details about collisions, please refer to patch 4's description.

changes since v1:
  - drop patch 'perf, core: Add all PMUs to pmu_idr'
  - add comments for case that multiple counters overflow simultaneously
changes since v2:
  - rename perf_sched_cb_{enable,disable} to perf_sched_cb_user_{inc,dec}
  - use flag to indicate auto reload mechanism
  - move codes that setup PEBS sample data to separate function
  - output the PEBS records in batch
  - enable this for All (PEBS capable) hardware
  - more description for the multiplex
changes since v3:
  - ignore conflicting PEBS record
changes since v4:
  - Do more tests for collision and update comments
changes since v5:
  - Move autoreload and large PEBS available check to intel_pmu_hw_config
  - make AUTO_RELOAD conditional on large PEBS
  - !PEBS bug fix
  - coherent story about what is collision and how we handle it.
  - Remove extra state pebs_sched_cb_enabled

Yan, Zheng (6):
  perf, x86: use the PEBS auto reload mechanism when possible
  perf, x86: introduce setup_pebs_sample_data()
  perf, x86: large PEBS interrupt threshold
  perf, x86: handle multiple records in PEBS buffer
  perf, x86: drain PEBS buffer during context switch
  perf, x86: enlarge PEBS buffer

 arch/x86/kernel/cpu/perf_event.c           |  15 +-
 arch/x86/kernel/cpu/perf_event.h           |  15 +-
 arch/x86/kernel/cpu/perf_event_intel.c     |  21 +-
 arch/x86/kernel/cpu/perf_event_intel_ds.c  | 316 ++++++++++++++++++++++-------
 arch/x86/kernel/cpu/perf_event_intel_lbr.c |   3 -
 include/linux/perf_event.h                 |   4 +
 kernel/events/core.c                       |   6 +-
 7 files changed, 293 insertions(+), 87 deletions(-)

-- 
1.7.11.7


             reply	other threads:[~2015-04-09 16:38 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-09 16:37 Kan Liang [this message]
2015-04-09 16:37 ` [PATCH V6 1/6] perf, x86: use the PEBS auto reload mechanism when possible Kan Liang
2015-04-09 16:37 ` [PATCH V6 2/6] perf, x86: introduce setup_pebs_sample_data() Kan Liang
2015-04-09 16:37 ` [PATCH V6 3/6] perf, x86: large PEBS interrupt threshold Kan Liang
2015-04-15 17:14   ` Peter Zijlstra
2015-04-15 17:48     ` Liang, Kan
2015-04-15 18:10       ` Peter Zijlstra
2015-04-15 18:05   ` Peter Zijlstra
2015-04-15 18:35     ` Liang, Kan
2015-04-15 18:41       ` Peter Zijlstra
2015-04-16 18:45   ` Peter Zijlstra
2015-04-09 16:37 ` [PATCH V6 4/6] perf, x86: handle multiple records in PEBS buffer Kan Liang
2015-04-09 21:01   ` Andi Kleen
2015-04-15 18:28   ` Peter Zijlstra
2015-04-15 18:36   ` Peter Zijlstra
2015-04-16 12:53   ` Peter Zijlstra
2015-04-17  8:11     ` Peter Zijlstra
2015-04-17 12:50       ` Liang, Kan
2015-04-17 13:12         ` Peter Zijlstra
2015-04-17 14:19           ` Liang, Kan
2015-04-17 14:44             ` Peter Zijlstra
2015-04-17 18:20               ` Andi Kleen
2015-04-17 18:25                 ` Peter Zijlstra
2015-04-09 16:37 ` [PATCH V6 5/6] perf, x86: drain PEBS buffer during context switch Kan Liang
2015-04-09 16:37 ` [PATCH V6 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=1428597466-8154-1-git-send-email-kan.liang@intel.com \
    --to=kan.liang@intel.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@infradead.org \
    --cc=andi@firstfloor.org \
    --cc=eranian@google.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