Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932572AbcC2Uqy (ORCPT ); Tue, 29 Mar 2016 16:46:54 -0400 Received: from casper.infradead.org ([85.118.1.10]:59555 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752522AbcC2Uqv (ORCPT ); Tue, 29 Mar 2016 16:46:51 -0400 Date: Tue, 29 Mar 2016 22:46:46 +0200 From: Peter Zijlstra To: Steven Rostedt Cc: Daniel Bristot de Oliveira , Ingo Molnar , Thomas Gleixner , Juri Lelli , Arnaldo Carvalho de Melo , LKML , linux-rt-users Subject: Re: [PATCH V2 3/3] sched/deadline: Tracepoints for deadline scheduler Message-ID: <20160329204646.GO3408@twins.programming.kicks-ass.net> References: <14f6caa05f73ceba69eff035ac542cad671552b3.1459182044.git.bristot@redhat.com> <20160329151649.GA12845@twins.programming.kicks-ass.net> <20160329115700.40acb336@gandalf.local.home> <20160329160401.GB3430@twins.programming.kicks-ass.net> <20160329131056.5b01780b@gandalf.local.home> <20160329201145.GC3430@twins.programming.kicks-ass.net> <20160329162907.418cb972@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160329162907.418cb972@gandalf.local.home> 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: 1105 Lines: 25 On Tue, Mar 29, 2016 at 04:29:07PM -0400, Steven Rostedt wrote: > On Tue, 29 Mar 2016 22:11:45 +0200 > Peter Zijlstra wrote: > > > > > Yes, we don't want to get rid of the old one. But it shouldn't break > > > anything if we extend it. I'm thinking of extending it with a dynamic > > > array to store the deadline task values (runtime, period). And for non > > > deadline tasks, the array would be empty (size zero). I think that > > > could be doable and maintain backward compatibility. > > > > Why the complexity? Why not just tack those 32 bytes on and get on with > > life? > > 32 bytes that are zero and meaningless for 99.999% of scheduling? > > The scheduling tracepoint is probably the most common tracepoint used, > and one of the frequent ones. 32bytes of wasted space per event can > cause a lot of tracing to be missed. Typically you don't schedule _that_ often. Sure if you run pipe-bench and hit ~.5e6 ctx/s its ~15M/s extra. But building a kernel gets me ~.5e3 ctx/s (per cpu), at which rate its 15K/s extra. But sure, if you want to make it fancy have at.