Messages in this thread | | | Date | Wed, 18 Dec 2013 14:34:39 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH v0 04/71] itrace: Infrastructure for instruction flow tracing units |
| |
On Wed, Dec 18, 2013 at 03:23:41PM +0200, Alexander Shishkin wrote: > Peter Zijlstra <peterz@infradead.org> writes: > > > On Wed, Dec 11, 2013 at 02:36:16PM +0200, Alexander Shishkin wrote: > >> Instruction tracing PMUs are capable of recording a log of instruction > >> execution flow on a cpu core, which can be useful for profiling and crash > >> analysis. This patch adds itrace infrastructure for perf events and the > >> rest of the kernel to use. > >> > >> Since such PMUs can produce copious amounts of trace data, it may be > >> impractical to process it inside the kernel in real time, but instead export > >> raw trace streams to userspace for subsequent analysis. Thus, itrace PMUs > >> may export their trace buffers, which can be mmap()ed to userspace from a > >> perf event fd with a PERF_EVENT_ITRACE_OFFSET offset. To that end, perf > >> is extended to work with multiple ring buffers per event, reusing the > >> ring_buffer code in an attempt to reduce complexity. > > > > Please read the thread here: https://lkml.org/lkml/2008/12/4/64 > > > > On my thoughts of this creative mmap() usage. > > That's unfortunate, it made sense to me. But let's then have a look at > the alternative approaches. Bearing in mind that it is crucial for us to > export trace buffers to userspace as opposed to processing the trace > data in the kernel, the fact that we still need the normal perf data > stream and your dislike for mmap trickery, we need two separate file > descriptors: one for the perf data and one for the trace data.
Why don't you start by explaining _why_ you need a second stream to begin with?
| |