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

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 29 Jun 2017 21:20:54 +0000 (UTC)
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> Our attempts at extending the Linux scheduler Tracepoints [1,2,3] to cover sched
> rt and deadline policies went fairly well until we reached the point where
> we had to extend the tracing ABI exposed to user-space by Ftrace through the
> DebugFS tracing sub-directory. We aim to expose more accurate and complete
> scheduler information (based on the scheduling class), and eventually deprecate
> implementation-specific fields that should never have been exposed to user-space
> in the first place.
> 
> Example of problems we are facing:
> 
>   * Humans on the receiving end of a kernel ABI
> 
>     Should we limit the design of kernel ABIs based on their direct
>     use by humans through echo and redirections, or can we aim design
>     of those interfaces at scripts and user-space programs/libraries ?

Well, that human is mainly Peter ;-)

But we also can't break tools that user the sched_switch tracepoint,
namely trace-cmd and perf, as well as powertop.

> 
>     A simple and extensible kernel ABI is rarely an easy to use end-user
>     interface.
> 
>   * How can we deprecate, remove, or re-purpose a field in an
>     event ? For instance, the "prio" field in the scheduler
>     instrumentation is an internal implementation detail.

One way is to fix all tools that use it and make sure they get out to
the distros before making the change.

> 
> Perhaps it would be good to use the opportunity to meet at the
> Kernel Summit and discuss this issue.

Agreed. In this topic, I would like to focus more on extending, or
implementations on overlaying tracepoints where one tracepoint exists
in the code, but there's multiple ways to display it.

-- Steve


> 
> Thanks,
> 
> Mathieu and Julien
> 
> 
> [1] [RFC PATCH 5/6] tracing: extend scheduling tracepoints
>     http://lkml.kernel.org/r/1474060148-13171-5-git-send-email-jdesfossez@efficios.com
> [2] [RFC PATCH v2 0/5] Additional scheduling information in tracepoints
>     http://lkml.kernel.org/r/1474649375-28056-1-git-send-email-jdesfossez@efficios.com
> [3] [RFC PATCH v3 0/2] Extend scheduling tracepoints
>     http://lkml.kernel.org/r/1484327993-5036-1-git-send-email-jdesfossez@efficios.com
>