Peter Zijlstra <pet...@infradead.org> writes: > On Wed, Dec 18, 2013 at 04:01:04PM +0200, Alexander Shishkin wrote: >> > Why don't you start by explaining _why_ you need a second stream to >> > begin with? >> >> Oh, I'm sure I've explained it earlier ([1], [2]) > > See, I didn't read 0 because that information gets lost and patches > should be self explanatory, and i didn't get to the Intel driver yet > because well, I got stuck in the generic code.
Sure. The general concept is more important than the actual driver at this point anyway. >> but why not. The data >> in the second stream is generated at a rate which is hundreds of >> megabytes per second per core. Decoding this data is ~1000 times slower >> than generating it. Ergo, can't be done in kernel, needs to be exported >> as-is to userspace for later retreival and decoding. Doing it via perf >> stream means an extra copy, which at these rates is a waste. Ergo, a >> second buffer. > > Still confused, if you cannot copy it into one buffer, then why can you > copy it into a second buffer? It's not copied, hardware writes directly into that second buffer. I've done the same with BTS now (as Ingo suggested) and it also benefits from this approach. Regards, -- Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/