Messages in this thread | | | From | Alexander Shishkin <> | Subject | Re: [PATCH v0 04/71] itrace: Infrastructure for instruction flow tracing units | Date | Wed, 18 Dec 2013 16:22:36 +0200 |
| |
Peter Zijlstra <peterz@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
| |