Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754019AbbDTPTm (ORCPT ); Mon, 20 Apr 2015 11:19:42 -0400 Received: from mga02.intel.com ([134.134.136.20]:60746 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751471AbbDTPTk (ORCPT ); Mon, 20 Apr 2015 11:19:40 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,609,1422950400"; d="scan'208";a="698006567" From: Kan Liang To: peterz@infradead.org Cc: mingo@kernel.org, acme@infradead.org, eranian@google.com, andi@firstfloor.org, linux-kernel@vger.kernel.org, Kan Liang Subject: [PATCH V7 0/6] large PEBS interrupt threshold Date: Mon, 20 Apr 2015 04:07:44 -0400 Message-Id: <1429517270-8079-1-git-send-email-kan.liang@intel.com> X-Mailer: git-send-email 1.8.3.1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3459 Lines: 79 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 4'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%. For details about collisions, please refer to patch 3'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 changes since v6: - new flag PERF_X86_EVENT_FREERUNNING to indicate large PEBS available - patch reorder and changelog changes for patch 1 and 3 - An easy way to clear !PEBS bit - Log collision to PERF_RECORD_SAMPLES_LOST Yan, Zheng (6): perf, x86: use the PEBS auto reload mechanism when possible perf, x86: introduce setup_pebs_sample_data() perf, x86: handle multiple records in PEBS buffer perf, x86: large PEBS interrupt threshold 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 | 35 +++- arch/x86/kernel/cpu/perf_event_intel.c | 22 +- arch/x86/kernel/cpu/perf_event_intel_ds.c | 324 +++++++++++++++++++++-------- arch/x86/kernel/cpu/perf_event_intel_lbr.c | 3 - include/linux/perf_event.h | 13 ++ kernel/events/core.c | 6 +- kernel/events/internal.h | 9 - 8 files changed, 312 insertions(+), 115 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/