Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752585AbbBKKPh (ORCPT ); Wed, 11 Feb 2015 05:15:37 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:38906 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752046AbbBKKPf (ORCPT ); Wed, 11 Feb 2015 05:15:35 -0500 Date: Wed, 11 Feb 2015 11:15:21 +0100 From: Peter Zijlstra To: Alexei Starovoitov Cc: Steven Rostedt , Ingo Molnar , Namhyung Kim , Arnaldo Carvalho de Melo , Jiri Olsa , Masami Hiramatsu , Linux API , Network Development , LKML , Linus Torvalds , "Eric W. Biederman" Subject: Re: [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls Message-ID: <20150211101521.GP23123@twins.programming.kicks-ass.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1908 Lines: 42 On Tue, Feb 10, 2015 at 04:22:50PM -0800, Alexei Starovoitov wrote: > > It would need to do more that that. It may have to calculate the value > > that it returns, as the internal value may be different with different > > kernels. > > back to 'prio'... the 'prio' accessible from the program > should be the same 'prio' that we're storing inside task_struct. Its not, task_struct::prio is an entirely different value than the one used in sched_param::sched_priority / sched_attr::sched_priority. And the 'problem' is, prio is only relevant to SCHED_RR/SCHED_FIFO tasks, we have more classes. > No extra conversions. We're not going to add runtime/space overhead to the kernel just because someone might maybe someday trace the kernel. That leaves the option of either tracing the kernel internal value and userspace will just have to deal with it, or making the tracepoint more expensive by having it do the conversion. Now the big question is, what do we do when we add/extend a scheduling class and have more parameters? We cannot change the tracepoint because userspace assumes format. And I simply refuse to add a second -- because that will end up being a third and fourth etc.. -- tracepoint right next to it with a different layout. Note that we just did add a class, we grew SCHED_DEADLINE a few releases ago, and that has 3 parameters (or 6 depending on how you look at it). You currently cannot 'debug' that with the existing tracepoints. In short, I loathe traceevents, they're more trouble than they're worth. Now I do love the infrastructure, its very useful debugging, but that's all with local hacks that will never see the light of day. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/