Messages in this thread | | | Subject | Re: [RFC/Requirements/Design] h/w error reporting | From | Steven Rostedt <> | Date | Wed, 10 Nov 2010 13:05:29 -0500 |
| |
On Wed, 2010-11-10 at 18:48 +0100, Ingo Molnar wrote:
> Yep. The obvious direction is to extend the event buffering ABI we already have, > with whatever additions that are needed: > > - document that we already support flight recorder mode
I thought this was still broken?
> > - a more compressed record format > > - NOP filler events up to page boundary, for better splice and for better flight > recorder > > - splice support > > etc. That's how it evolved until now and it's all very extensible. > > Steve, could you please list the additions you have in mind, in order of priority?
A few of things that pop up quickly are:
1) lockless
2) as-fast-as possible
3) support all tasks / all CPUs and still have as-fast-as-possible
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.
I think if we take a step back, we can come up with a new buffering/ABI system that can satisfy everyone. We will still support the current method now, but I really don't think it is designed with everything we had in mind. I do not envision that we can "envolve" to where we want to be. We may have to bite the bullet, just like iptables did when they saw the failures of ipchains, and redesign something new now that we understand what the requirements are.
I do think we need to come up with something new but still support the old methods. Thomas came up with this idea, and Peter, Frederic and myself agreed.
-- Steve
| |