[Ksummit-discuss] [TECH TOPIC] Pulling away from the tracing ABI quicksands
Steven Rostedt
rostedt at goodmis.org
Thu Jun 29 23:55:37 UTC 2017
On Thu, 29 Jun 2017 21:20:54 +0000 (UTC)
Mathieu Desnoyers <mathieu.desnoyers at 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
>
More information about the Ksummit-discuss
mailing list