From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754027AbdBGMYI (ORCPT ); Tue, 7 Feb 2017 07:24:08 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:42904 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752624AbdBGMYH (ORCPT ); Tue, 7 Feb 2017 07:24:07 -0500 Date: Tue, 7 Feb 2017 13:23:56 +0100 From: Peter Zijlstra To: Julien Desfossez Cc: rostedt@goodmis.org, tglx@linutronix.de, mingo@redhat.com, bristot@redhat.com, mathieu.desnoyers@efficios.com, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v3 2/2] tracing: add policy-based sched_switch events Message-ID: <20170207122356.GQ6515@twins.programming.kicks-ass.net> References: <1484327993-5036-1-git-send-email-jdesfossez@efficios.com> <1484327993-5036-3-git-send-email-jdesfossez@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1484327993-5036-3-git-send-email-jdesfossez@efficios.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 13, 2017 at 12:19:53PM -0500, Julien Desfossez wrote: > Add 3 new tracepoints: sched_switch_fair, sched_switch_rt and > sched_switch_dl. Do they really _have_ to be whole new tracepoints? I really don't like littering the user interface with all that. Furthermore, it doesn't seem to make sense to enable these individually, either all or none. > These conditional tracepoints are emitted based on the scheduling class > of the next task. Each of these tracepoint gets rid of the prio field > from the original sched_switch and replaces it with fields that are > relevant to the policy of the next task: > - for a fair task: the nice value, > - for a rt task: the nice and rt_priority values, Nice is not relevant to RT. > - for a dl task: the runtime, deadline and period values. > > The original sched_switch event is left unmodified, so these new events > can be enabled at the same time (but they are emitted consecutively so > we can see a timestamp offset). So ideally there would only be _1_ sched_switch event that I can enable, and it would (per default) not print the old style at all. Some (global?) compat knob could be used to switch back to the old style output with clear notification that that is going to go away 'soon'.