From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754063AbdDMOMK (ORCPT ); Thu, 13 Apr 2017 10:12:10 -0400 Received: from mail.kernel.org ([198.145.29.136]:37954 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753772AbdDMOMI (ORCPT ); Thu, 13 Apr 2017 10:12:08 -0400 Date: Thu, 13 Apr 2017 10:12:03 -0400 From: Steven Rostedt To: Mel Gorman Cc: LKML , Peter Zijlstra , Ingo Molnar , Matt Fleming , Srikar Dronamraju , Josh Poimboeuf Subject: Re: [PATCH v2] sched: Enabled schedstat when schedstat tracepoints are enabled Message-ID: <20170413101203.72e7fd5f@gandalf.local.home> In-Reply-To: <20170413100118.rggxbhlgluynysmp@suse.de> References: <20170412160432.481ee5fb@gandalf.local.home> <20170413100118.rggxbhlgluynysmp@suse.de> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; 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 Thu, 13 Apr 2017 11:01:19 +0100 Mel Gorman wrote: > On Wed, Apr 12, 2017 at 10:56:07PM -0400, Steven Rostedt wrote: > > From: Steven Rostedt (VMware) > > > > During my tests, I see this in my dmesg: > > > > "Scheduler tracepoints stat_sleep, stat_iowait, stat_blocked and > > stat_runtime require the kernel parameter schedstats=enabled or > > kernel.sched_schedstats=1" > > > > And found the commit: > > > > cb2517653fc ("sched/debug: Make schedstats a runtime tunable that is > > disabled by default") > > > > Which states: > > > > "For tracepoints, there is a simple warning as it's not safe to activate > > schedstats in the context when it's known the tracepoint may be wanted > > but is unavailable." > > > > I'm assuming that Mel did not know about the TRACE_EVENT_FN() and > > DEFINE_EVENT_FN() that allow for callbacks for tracepoints as they are > > enabled and disabled. I do not see any reason for not enabling > > schedstat when one of its tracepoints are enabled. > > > > The state of schedstat is saved when the first tracepoint is enabled, > > and that state is put back when the tracepoints are disabled. > > > > Signed-off-by: Steven Rostedt (VMware) > > You're right, I wasn't aware. Patch looks ok. When it triggers, there > will be a short interval of garbage numbers but that's the same as what > happens currently. It's not deliberate action any more that would flag > to the user that there is a hazard but I think it'll be manageable. I wonder if there's a way to figure out when the measurements are no longer garbage, and have a tracepoint or something to notify the user applications that they are good to go? Or perhaps even suppress the tracepoints (TRACE_EVENT_FN_COND) until they are stable. > > Acked-by: Mel Gorman Thanks! -- Steve