linux-kernel - Re: [lttng-dev] Clarification on SCHED_FIFO support

Open Source and information security mailing list archives

Date:   Wed, 28 Jun 2017 18:22:38 +0000 (UTC)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     Sukanya Sekar <ssekar@...rew.cmu.edu>
Cc:     lttng-dev <lttng-dev@...ts.lttng.org>,
        Julien Desfossez <jdesfossez@...icios.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        rostedt <rostedt@...dmis.org>, bristot <bristot@...hat.com>
Subject: Re: [lttng-dev] Clarification on SCHED_FIFO support

----- On Jun 27, 2017, at 7:36 PM, Sukanya Sekar ssekar@...rew.cmu.edu wrote:

> Greetings!
> We are exploring the LTTng Kernel Tracer (version 2.9) on Ubuntu 16.04. We are
> particularly interested in real-time applications. As far as we explored, we
> couldn't find support for SCHED_FIFO events. Also, we found a comment in the
> source code (.../sched.h) indicating that the sched_stat support to
> SCHED_FIFO/RR is yet to be added.

> So we would like to confirm if SCHED_FIFO isn't supported in the latest version
> of the tool.

This is a problem in the upstream Linux kernel instrumentation.

I am assuming you refer to the sched_stat_template event class, used by 
sched_stat_wait, sched_stat_sleep, sched_stat_iowait, and sched_stat_blocked 
events. For those specific events, LTTng modules has the same limitation as 
the Linux kernel scheduler instrumentation, where we find this comment 
(include/trace/events/sched.h): 

/* 
* XXX the below sched_stat tracepoints only apply to SCHED_OTHER/BATCH/IDLE 
* adding sched_stat support to SCHED_FIFO/RR would be welcome. 
*/ 

This is not specific to LTTng. Ftrace, Perf, and SystemTAP have the same limitation 
when using this scheduler tracepoint. 

In the past year, Julien Desfossez proposed enhancements to the Linux kernel 
scheduler instrumentation [1], but there are still some disagreements on how
to expose the new interfaces to user-space. 

Through a follow up IRC discussion we had with Peter Zijlstra and Steven Rostedt,
we found out that they have opinions on how to evolve the kernel ABI exposed by
Ftrace and Perf (keeping a single event for sched_switch, not having unneeded
information in the event, exposing multiple numbered event format files format,
format2, format3..., cumulative enabling semantic (enabling format3 enables format2 and 
format), and so on), but the set of requirements is still unclear, and they have not 
formulated an ABI proposal that those involved generally agree on. 

IMHO, part of the issue here is to mistake kernel ABIs for end user tooling interfaces. 
If, for instance, trace-cmd exposes the new sched_switch_{rt,fail,dl} events as a single 
synthetic sched_switch event from a user perspective, what do we really gain by
complexifying the kernel ABI to still allow enabling a single event instead of 3 using
"echo" from a shell ?

As soon as the Linux kernel adds the proper instrumentation to deal with those 
scheduler policies, we will add support for it in LTTng (only for the newer kernels 
that contain that instrumentation, of course). 

Thanks, 

Mathieu 

[1] https://lkml.org/lkml/2017/1/13/624 

> Thanks,
> Sukanya

> _______________________________________________
> lttng-dev mailing list
> lttng-dev@...ts.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives