Re: [PATCH v0 04/71] itrace: Infrastructure for instruction flowtracing units

[Peter Zijlstra]

On Thu, Dec 19, 2013 at 01:17:51PM +0200, Alexander Shishkin wrote:
> Peter Zijlstra <peterz@xxxxxxxxxxxxx> writes:
> 
> > On Thu, Dec 19, 2013 at 09:53:44AM +0200, Alexander Shishkin wrote:
> >> Yes and some implementations of PT have the same issue, but you can do a
> >> sufficiently large high order allocation and map it to userspace and
> >> still no copying (or parsing/decoding) in kernel space required.
> >
> > What's sufficiently large? The largest we could possibly allocate is
> > something like 4k^11 which is 8M or so. That's not all that big given
> > you keep saying it generates in the order of 100 MB/s.
> 
> One chunk is 8M. You can have as many as the buddy allocator permits you
> to have. When you get a PMI, you simply switch one chunk for another and
> on the tracing goes.

This document you referred me to looks to specify something with a
proper s/g implementation; called ToPA. There doesn't appear to be a
limit to the linked entries and you can specify a size per entry, and I
don't see anywhere why 4k would be bad.

That said, I'm still reading..

> > Also, 'some implementations', that sounds like a fail right there. Why
> > are there already different implementations, and some which such stupid
> > design, of something this new?
> >
> > How about just saying NO to the ones that requires physically contiguous
> > allocations?
> 
> No reason to leave those out, because they are still extremely useful
> for tracing and fit perfectly fine in a model with two buffers.

Maybe; but lets start with the sane hardware. Then we'll look at the
amount of pain needed to support these broken pieces of crap and decide
later.

So drop all support for crappy hardware now.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/