From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756228AbdDMKBX (ORCPT ); Thu, 13 Apr 2017 06:01:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:48946 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751424AbdDMKBW (ORCPT ); Thu, 13 Apr 2017 06:01:22 -0400 Date: Thu, 13 Apr 2017 11:01:19 +0100 From: Mel Gorman To: Steven Rostedt Cc: LKML , Peter Zijlstra , Ingo Molnar , Matt Fleming , Srikar Dronamraju Subject: Re: [PATCH v2] sched: Enabled schedstat when schedstat tracepoints are enabled Message-ID: <20170413100118.rggxbhlgluynysmp@suse.de> References: <20170412160432.481ee5fb@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20170412160432.481ee5fb@gandalf.local.home> User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Acked-by: Mel Gorman Thanks Steven. -- Mel Gorman SUSE Labs