From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753412AbbE0KIm (ORCPT ); Wed, 27 May 2015 06:08:42 -0400 Received: from terminus.zytor.com ([198.137.202.10]:33654 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750755AbbE0KIh (ORCPT ); Wed, 27 May 2015 06:08:37 -0400 Date: Wed, 27 May 2015 03:07:59 -0700 From: tip-bot for Alexander Shishkin Message-ID: Cc: hpa@zytor.com, mingo@kernel.org, paulus@samba.org, linux-kernel@vger.kernel.org, peterz@infradead.org, alexander.shishkin@linux.intel.com, torvalds@linux-foundation.org, tglx@linutronix.de Reply-To: hpa@zytor.com, paulus@samba.org, mingo@kernel.org, peterz@infradead.org, linux-kernel@vger.kernel.org, alexander.shishkin@linux.intel.com, tglx@linutronix.de, torvalds@linux-foundation.org In-Reply-To: <1429622177-22843-4-git-send-email-alexander.shishkin@linux.intel.com> References: <1429622177-22843-4-git-send-email-alexander.shishkin@linux.intel.com> To: linux-tip-commits@vger.kernel.org Subject: [tip:perf/core] perf/x86/intel/pt: Document pt_buffer_reset_markers() Git-Commit-ID: cf302bfdf3039853fce812ae1ffd0ac24f5b468f X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: cf302bfdf3039853fce812ae1ffd0ac24f5b468f Gitweb: http://git.kernel.org/tip/cf302bfdf3039853fce812ae1ffd0ac24f5b468f Author: Alexander Shishkin AuthorDate: Tue, 21 Apr 2015 16:16:15 +0300 Committer: Ingo Molnar CommitDate: Wed, 27 May 2015 09:17:47 +0200 perf/x86/intel/pt: Document pt_buffer_reset_markers() The comments in the driver don't make it absolutely clear as to what exactly is the calling order and other possible constraints of buffer management functions. Document constraints and calling order for the buffer configuration functions. While at it, replace a redundant check in pt_buffer_reset_markers() with an explanation why it is not needed. Signed-off-by: Alexander Shishkin Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: acme@infradead.org Cc: adrian.hunter@intel.com Cc: hpa@zytor.com Link: http://lkml.kernel.org/r/1429622177-22843-4-git-send-email-alexander.shishkin@linux.intel.com Signed-off-by: Ingo Molnar --- arch/x86/kernel/cpu/perf_event_intel_pt.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/cpu/perf_event_intel_pt.c b/arch/x86/kernel/cpu/perf_event_intel_pt.c index 8a45956..b2746ea 100644 --- a/arch/x86/kernel/cpu/perf_event_intel_pt.c +++ b/arch/x86/kernel/cpu/perf_event_intel_pt.c @@ -609,7 +609,12 @@ static unsigned int pt_topa_next_entry(struct pt_buffer *buf, unsigned int pg) * @handle: Current output handle. * * Place INT and STOP marks to prevent overwriting old data that the consumer - * hasn't yet collected. + * hasn't yet collected and waking up the consumer after a certain fraction of + * the buffer has filled up. Only needed and sensible for non-snapshot counters. + * + * This obviously relies on buf::head to figure out buffer markers, so it has + * to be called after pt_buffer_reset_offsets() and before the hardware tracing + * is enabled. */ static int pt_buffer_reset_markers(struct pt_buffer *buf, struct perf_output_handle *handle) @@ -618,9 +623,6 @@ static int pt_buffer_reset_markers(struct pt_buffer *buf, unsigned long head = local64_read(&buf->head); unsigned long idx, npages, wakeup; - if (buf->snapshot) - return 0; - /* can't stop in the middle of an output region */ if (buf->output_off + handle->size + 1 < sizes(TOPA_ENTRY(buf->cur, buf->cur_idx)->size)) @@ -901,6 +903,7 @@ void intel_pt_interrupt(void) } pt_buffer_reset_offsets(buf, pt->handle.head); + /* snapshot counters don't use PMI, so it's safe */ ret = pt_buffer_reset_markers(buf, &pt->handle); if (ret) { perf_aux_output_end(&pt->handle, 0, true);