Re: [Ksummit-discuss] [TECH TOPIC] Pulling away from the tracing ABI quicksands

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 29 Jun 2017 20:32:24 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:


> The problem we have is how to implement it?
> 
> We could make one tracepoint hook location have several different
> "tracepoints" in the tracefs directory letting the user choose how much
> information they want to trace. Have different tracepoints that can be
> enabled for a single location, where it may show extended fields.
> 
> I know people would like to have a way to cut down some fields, as
> real-estate in the ring buffer is of high value, and the smaller the
> events are, the more data one can collect. People who use tracing
> really do care about any wasted space (which is why we like to avoid
> writing zeros in fields no longer valued, it makes it harder to get the
> data you are after).
> 
> In summary, this is not another beat the dead horse how to do stable
> tracepoints. The focus is, how to make tracepoints more user
> customizable for their use cases.

Just to explain what Mathieu was talking about with echo and such, is
that Peter Zijlstra has been against multiple tracepoints for that one
sched switch location. He would prefer a dynamic case, instead of
having to enable all tracepoints, to get full functionality, as he
tends to use echo / cat to interact with ftrace than by using the
tools. He doesn't want the hassle of enabling more than one tracepoint
for sched_switch. One could call him lazy ;) but he's also the
maintainer of that tracepoint!

What would be really nice is a way to have sched_switch be a dynamic
tracepoint where it can trace differently depending on what is being
scheduled in and out. I'm sure other tracepoints locations may want a
similar feature.

But the devil is in the details of implementation, and we need to do
all this without breaking the existing tools that use the tracing
system. (See I have been listening to you!)

-- Steve