From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753697AbcBVRtB (ORCPT ); Mon, 22 Feb 2016 12:49:01 -0500 Received: from smtprelay0127.hostedemail.com ([216.40.44.127]:40802 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752567AbcBVRs7 (ORCPT ); Mon, 22 Feb 2016 12:48:59 -0500 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,rostedt@goodmis.org,:::::::::::::::,RULES_HIT:41:355:379:541:599:800:960:973:988:989:1260:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1541:1593:1594:1711:1730:1747:1777:1792:2376:2393:2553:2559:2562:2689:2892:3138:3139:3140:3141:3142:3352:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:5007:6119:6261:7875:7903:10004:10400:10848:10967:11232:11658:11914:12296:12517:12519:12663:12740:13069:13161:13229:13311:13357:13618:14096:14097:14659:21080:21324:30054:30075:30090:30091,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:3,LUA_SUMMARY:none X-HE-Tag: desk59_3100736736f1c X-Filterd-Recvd-Size: 2238 Date: Mon, 22 Feb 2016 12:48:54 -0500 From: Steven Rostedt To: Peter Zijlstra Cc: Daniel Bristot de Oliveira , Ingo Molnar , Thomas Gleixner , Juri Lelli , Arnaldo Carvalho de Melo , LKML , linux-rt-users Subject: Re: [PATCH 3/4] sched/deadline: Tracepoints for deadline scheduler Message-ID: <20160222124854.3816fec4@gandalf.local.home> In-Reply-To: <20160222173259.GM6357@twins.programming.kicks-ass.net> References: <20160222173259.GM6357@twins.programming.kicks-ass.net> X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; 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 Mon, 22 Feb 2016 18:32:59 +0100 Peter Zijlstra wrote: > So I'm a bit allergic to tracepoints and this is very flimsy on reasons > why I would want to do this. Because there's no way to know if SCHED_DEADLINE tasks are doing what they suppose to without hacking the kernel and adding your own tracepoints. > > As it stands, the existing tracepoint have already been an ABI > trainwreck, why would I want to add more? Yes, this may become a type of ABI, but even the sched switch tracepoints haven't been that bad. Has it really prevented us from changing anything? "trainwreck" is a harsh word, and the information of scheduling tracepoints have been crucial to finding bugs and such. And has been tremendously useful in loads of cases. But let me ask, what would you recommend to finding out if the kernel has really given your tasks the recommended runtime within a given period? We can't expect users of SCHED_DEADLINE to be modifying the kernel themselves. -- Steve