From: Mel Gorman <mgorman@suse.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Matt Fleming <matt@codeblueprint.co.uk>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Subject: Re: [PATCH v2] sched: Enabled schedstat when schedstat tracepoints are enabled
Date: Thu, 13 Apr 2017 11:01:19 +0100 [thread overview]
Message-ID: <20170413100118.rggxbhlgluynysmp@suse.de> (raw)
In-Reply-To: <20170412160432.481ee5fb@gandalf.local.home>
On Wed, Apr 12, 2017 at 10:56:07PM -0400, Steven Rostedt wrote:
> From: Steven Rostedt (VMware) <rostedt@goodmis.org>
>
> 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) <rostedt@goodmis.org>
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 <mgorman@suse.de>
Thanks Steven.
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2017-04-13 10:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-12 20:04 [PATCH] " Steven Rostedt
2017-04-13 2:02 ` kbuild test robot
2017-04-13 9:00 ` [PATCH v2] " Peter Zijlstra
2017-04-13 9:01 ` Peter Zijlstra
2017-04-13 14:08 ` Steven Rostedt
2017-04-13 10:01 ` Mel Gorman [this message]
2017-04-13 14:12 ` Steven Rostedt
2017-04-13 11:05 ` Srikar Dronamraju
2017-04-13 14:14 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170413100118.rggxbhlgluynysmp@suse.de \
--to=mgorman@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=srikar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®