Peter Zijlstra <pet...@infradead.org> writes: > On Thu, Dec 19, 2013 at 04:30:53PM +0200, Alexander Shishkin wrote: >> So I'd like to steer away from the ways in which hardware can be broken >> and talk about a usable interface, to begin with. > > Just dump it into the regular one buffer like I outlined.
Just getting back to this. Do you realize that PT buffers have to be page aligned. So to mix it with a regular perf buffer would need padding every PT message by 4K, which wastes a lot of memory. The side band messages are usually only a few bytes (e.g. context switch). If the sideband is mfrequent it could even take up >half of the buffer, but mostly only with padding. Is that what you intended? perf doesn't support gaps today, so your proposal wouldn't even seem to fit into the current perf design. Also of course it requires disabling/enabling PT explicitly for every perf message, which is slow. So you add at least 2*WRMSR cost (thousands of cycles). > That said; we very much need to have at least two architectures > implemented for any of this code to move. > > But we cannot ignore the hardware trainwreck; we cannot shape our > interface around something that's utterly broken. > > Some hardware is just too broken to support. I don't think the PT design is broken in any way, it's straight forward and simple. Trying to mix hardware tracing and software tracing in the same buffer on the other hand ... Anyways if perf is not flexible enough to support this I suppose it could switch to a simple device driver, and only run perf with separate fds for side band purposes. Would you prefer that? -Andi -- a...@linux.intel.com -- Speaking for myself only -- 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/
