From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934864AbbI2Pya (ORCPT ); Tue, 29 Sep 2015 11:54:30 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:52236 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933283AbbI2PyX (ORCPT ); Tue, 29 Sep 2015 11:54:23 -0400 Date: Tue, 29 Sep 2015 17:48:28 +0200 From: Peter Zijlstra To: Steven Rostedt Cc: mingo@kernel.org, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, fweisbec@gmail.com, oleg@redhat.com, umgwanakikbuti@gmail.com, tglx@linutronix.de Subject: Re: [RFC][PATCH 06/11] sched: Fix trace_sched_switch() Message-ID: <20150929154828.GS3816@twins.programming.kicks-ass.net> References: <20150929092825.540553633@infradead.org> <20150929093520.240883073@infradead.org> <20150929113812.0bc594d0@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150929113812.0bc594d0@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 On Tue, Sep 29, 2015 at 11:38:12AM -0400, Steven Rostedt wrote: > On Tue, 29 Sep 2015 11:28:31 +0200 > Peter Zijlstra wrote: > > > +static inline long __trace_sched_switch_state(bool preempt, struct task_struct *p) > > { > > + return preempt ? TASK_RUNNING | TASK_STATE_MAX : p->state; > > } > > Hmm, this original change screwed up kernelshark, as it used the > state to determine if something was preempted or not. Because now you > always show a task as running, it can't do that anymore. I think I > bitched about this before. > > What about nuking the above and just export to the sched_switch > tracepoint the fact that it was preempted. We now have that information > passed to it. > > As everything should be using the parsing files, it should not break > any tools to export it. /SHOULD/ being the operative word. Experience has taught me that changing the sched tracepoint leads to borkage. But we can sure try, see if someone notices etc.. Same with trace_sched_wakeup(), that still prints a dummy value.