From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751647AbdF1TFh (ORCPT ); Wed, 28 Jun 2017 15:05:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:51514 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751501AbdF1TFb (ORCPT ); Wed, 28 Jun 2017 15:05:31 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 716D4217C3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Wed, 28 Jun 2017 15:05:26 -0400 From: Steven Rostedt To: Mathieu Desnoyers Cc: Sukanya Sekar , lttng-dev , Julien Desfossez , linux-kernel , Peter Zijlstra , bristot Subject: Re: [lttng-dev] Clarification on SCHED_FIFO support Message-ID: <20170628150526.3f54c3f7@gandalf.local.home> In-Reply-To: <57299872.4472.1498674158120.JavaMail.zimbra@efficios.com> References: <57299872.4472.1498674158120.JavaMail.zimbra@efficios.com> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 28 Jun 2017 18:22:38 +0000 (UTC) Mathieu Desnoyers wrote: > ----- On Jun 27, 2017, at 7:36 PM, Sukanya Sekar ssekar@andrew.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). > You can propose settling this as a [TECH TOPIC] for kernel summit in Prague. -- Steve