public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andi Kleen <ak@linux.intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Mike Galbraith <efault@gmx.de>, Paul Mackerras <paulus@samba.org>,
	Stephane Eranian <eranian@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Matt Fleming <matt.fleming@intel.com>
Subject: Re: [PATCH v1 03/11] perf: Allow for multiple ring buffers per event
Date: Wed, 7 May 2014 23:22:24 +0200	[thread overview]
Message-ID: <20140507212224.GC2844@laptop.programming.kicks-ass.net> (raw)
In-Reply-To: <20140507210843.GS19657@tassilo.jf.intel.com>

On Wed, May 07, 2014 at 02:08:43PM -0700, Andi Kleen wrote:
> > Then, when data inside that aux data store changes they should inject an
> > PERF_RECORD_AUX to indicate this did happen, which ties it back into the
> > normal event flow.
> 
> What happens when the aux buffer wraps? How would the client know
> if the data belongs to this _AUX entry or some later one?

It belongs to the last one. Rewind them from 'now' until you hit
collisions in AUX space, then you're done.

> May need some extra sequence numbers in the mmap header and the aux
> entry to handle this.

You're thinking of overwrite mode, right? We should update the tail in
that case, I've not thought about how to do that for the AUX buffer.

There have been some patches for the normal buffer, but they stalled;

https://lkml.org/lkml/2013/7/8/154

I'm all for merging that patch (or a fixed on, since it has fail in) if
we can show the current !overwrite case doesn't regress.

Also, would anybody want different mode for the data and aux parts? In
that case we do need to add some extra state to the control page to
indicate such.

  reply	other threads:[~2014-05-07 21:22 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-06 10:50 [PATCH v1 00/11] perf: Add support for Intel Processor Trace Alexander Shishkin
2014-02-06 10:50 ` [PATCH v1 01/11] x86: Add Intel Processor Trace (INTEL_PT) cpu feature detection Alexander Shishkin
2014-02-06 10:50 ` [PATCH v1 02/11] perf: Abstract ring_buffer backing store operations Alexander Shishkin
2014-02-06 10:50 ` [PATCH v1 03/11] perf: Allow for multiple ring buffers per event Alexander Shishkin
2014-02-17 14:33   ` Peter Zijlstra
2014-02-18  2:36     ` Andi Kleen
2014-03-14 10:38       ` Peter Zijlstra
2014-03-14 14:10         ` Andi Kleen
2014-03-18 14:06           ` Alexander Shishkin
2014-02-19 22:02     ` Dave Hansen
2014-03-10  9:59       ` Alexander Shishkin
2014-03-10 17:24         ` Andi Kleen
2014-03-14 10:44           ` Peter Zijlstra
2014-03-14 14:13             ` Andi Kleen
2014-03-14 10:41       ` Peter Zijlstra
2014-05-07 15:26   ` Peter Zijlstra
2014-05-07 19:25     ` Ingo Molnar
2014-05-07 21:08     ` Andi Kleen
2014-05-07 21:22       ` Peter Zijlstra [this message]
2014-05-08  3:26         ` Alexander Shishkin
2014-05-08  4:05     ` Alexander Shishkin
2014-05-08  9:08       ` Alexander Shishkin
2014-05-08 12:34     ` Alexander Shishkin
2014-05-08 12:41       ` Peter Zijlstra
2014-05-08 12:46         ` Alexander Shishkin
2014-05-08 14:16           ` Peter Zijlstra
2014-02-06 10:50 ` [PATCH v1 04/11] itrace: Infrastructure for instruction flow tracing units Alexander Shishkin
2014-02-06 10:50 ` [PATCH v1 05/11] itrace: Add functionality to include traces in perf event samples Alexander Shishkin
2014-02-06 10:50 ` [PATCH v1 06/11] itrace: Add functionality to include traces in process core dumps Alexander Shishkin
2014-02-06 10:50 ` [PATCH v1 07/11] x86: perf: intel_pt: Intel PT PMU driver Alexander Shishkin
2014-02-06 20:29   ` Andi Kleen
2014-02-17 14:44   ` Peter Zijlstra
2014-02-17 16:07     ` Andi Kleen
2014-02-17 14:46   ` Peter Zijlstra
2014-02-18 12:42     ` Alexander Shishkin
2014-02-06 10:50 ` [PATCH v1 08/11] x86: perf: intel_pt: Add sampling functionality Alexander Shishkin
2014-02-06 10:50 ` [PATCH v1 09/11] x86: perf: intel_pt: Add core dump functionality Alexander Shishkin
2014-02-06 20:36   ` Andi Kleen
2014-02-07  9:03     ` Alexander Shishkin
2014-02-06 23:59   ` Andi Kleen
2014-02-07  9:09     ` Alexander Shishkin
2014-02-06 10:50 ` [PATCH v1 10/11] x86: perf: intel_bts: Add BTS PMU driver Alexander Shishkin
2014-02-06 10:50 ` [PATCH v1 11/11] x86: perf: intel_bts: Add core dump related functionality Alexander Shishkin
2014-02-06 23:57   ` Andi Kleen
2014-02-07  9:02     ` Alexander Shishkin

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=20140507212224.GC2844@laptop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=efault@gmx.de \
    --cc=eranian@google.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt.fleming@intel.com \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.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