Re: [RFC/Requirements/Design] h/w error reporting

[Steven Rostedt]

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


--
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/