From: Ingo Molnar <mingo@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
Jiri Olsa <jolsa@kernel.org>,
linux-kernel@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: perf,tools: Remove usage of trace_sched_wakeup(.success)
Date: Tue, 13 May 2014 19:14:36 +0200 [thread overview]
Message-ID: <20140513171436.GA8672@gmail.com> (raw)
In-Reply-To: <20140513100333.GW30445@twins.programming.kicks-ass.net>
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, May 13, 2014 at 03:34:32PM +0900, Dongsheng Yang wrote:
> > On 05/13/2014 04:22 PM, Ingo Molnar wrote:
> > >* Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > >>trace_sched_wakeup(.success) is a dead argument and has been for ages,
> > >Always 0, or random value?
> >
> > Hi Ingo,
> >
> > It is always 1 currently.
> >
> > Peter believe that .success is not useful and I pointed that perf
> > sched latency is using it now. Then he post this patch to remove
> > the usage here.
> >
> > Please go to the following link for more about this issue.
>
> It is _not_ usable. You're proposing to abuse the existing
> parameter. A wakeup doing an enqueue or not has nothing
> _WHAT_SO_EVER_ to do with success.
>
> Now what I think you wanted to do is make it easier to match
> trace_sched_switch() statements with trace_sched_wakeup()
> statements. And since you only get the trace_sched_switch() on
> dequeue, you want to know which trace_sched_wakeup() calls did an
> enqueue.
>
> But that's completely and utterly unrelated to success.
So I always considered it 'the enqueue was successful' - that's I
think why I added it to 'perf sched' originally - to be able to trace
wakeups from originator to target.
Thans,
Ingo
next prev parent reply other threads:[~2014-05-13 17:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-12 18:19 perf,tools: Remove usage of trace_sched_wakeup(.success) Peter Zijlstra
2014-05-13 1:38 ` [PATCH] perf_tools/sched: Remove nr_state_machine_bugs in perf latency Dongsheng Yang
2014-05-13 1:42 ` Dongsheng Yang
2014-05-13 11:56 ` Jiri Olsa
2014-05-19 11:59 ` Jiri Olsa
2014-05-21 9:25 ` Peter Zijlstra
2014-05-21 5:54 ` [tip:perf/core] perf sched: " tip-bot for Dongsheng Yang
2014-05-13 7:22 ` perf,tools: Remove usage of trace_sched_wakeup(.success) Ingo Molnar
2014-05-13 6:34 ` Dongsheng Yang
2014-05-13 10:03 ` Peter Zijlstra
2014-05-13 10:10 ` Dongsheng Yang
2014-05-13 11:26 ` Peter Zijlstra
2014-05-13 17:14 ` Ingo Molnar [this message]
2014-05-13 17:30 ` Peter Zijlstra
2014-05-13 18:15 ` Peter Zijlstra
2014-05-13 10:00 ` Peter Zijlstra
2014-05-21 5:54 ` [tip:perf/core] perf tools: Remove usage of trace_sched_wakeup( .success) tip-bot for Peter Zijlstra
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=20140513171436.GA8672@gmail.com \
--to=mingo@kernel.org \
--cc=acme@infradead.org \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=yangds.fnst@cn.fujitsu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.