* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:

quoted text
> On Wed, 2010-11-10 at 13:05 -0500, Steven Rostedt wrote:
> 
> > Peter said at LPC that the perf buffering system was not designed to handle high 
> > speed tracing. But he also said he does not like the way the ftrace buffering 
> > works.
> 
> You're not very good at listening, I said the perf infrastructure and event 
> handling mechanism isn't geared towards full throughput but instead on sampling.

Note that even that is an implementational detail that can be changed: even with a 
sampling model the sampling bits are in a flag word, so common combinations can be 
checked for quickly and open-coded into flat fall-through code - if the sample 
decoding ever shows up as overhead. (It doesnt even need any ABI changes.)

So it's a non-issue.

quoted text
> There is lots of code between getting the event and landing it in the buffer. The 
> buffer itself is perfectly suited for high speed low overhead stuffs, the perf 
> data format possibly not because its not bitfield happy.

Even that can be tweaked via allowing more compressed records. I doubt it will help 
as much, but it's still an incremental change that can be validated carefully.

Fact is that we have an ABI, happy users, happy tools and happy developers, so going 
incrementally is important and allows us to validate and measure every step while 
still having a full tool-space in place - and it will help everyone, in addition to 
the ftrace/lttng usecases.

We'll need to embark on this incremental path instead of a rewrite-the-world thing. 
As a maintainer my task is to say 'no' to rewrite-the-world approaches - and we can 
and will do better here.

Thanks,

	Ingo
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/