From: Peter Zijlstra <peterz@infradead.org>
To: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
Cc: Ingo Molnar <mingo@kernel.org>,
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 13:26:58 +0200 [thread overview]
Message-ID: <20140513112658.GX11096@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <5371EF7A.7060908@cn.fujitsu.com>
[-- Attachment #1: Type: text/plain, Size: 965 bytes --]
On Tue, May 13, 2014 at 07:10:02PM +0900, Dongsheng Yang wrote:
> On 05/13/2014 07:03 PM, Peter Zijlstra wrote:
> >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.
>
> Ha, yes, indeed. In perf sched latency, we need to know the timestamp
> when a task enqueue and then we can calculate the delay time.
> So I want to take the use of success parameter in trace_sched_wakeup()
> to indicate that *this* wakeup did an enqueue.
>
> But now I think it is okey if you really mind adding more tracepoints in
> scheduler. And I posted a patch after your patch in this thread to make
> perf sched latency work well.
I don't mind adding them per-se, as long as there's a reasonable effort
showing it doesn't slow down the wakeup-path.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-05-13 11:27 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 [this message]
2014-05-13 17:14 ` Ingo Molnar
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=20140513112658.GX11096@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@infradead.org \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.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.