From: Peter Zijlstra <peterz@infradead.org>
To: Song Liu <songliubraving@fb.com>
Cc: linux-kernel@vger.kernel.org, kernel-team@fb.com, tj@kernel.org,
jolsa@kernel.org
Subject: Re: [RFC 2/2] perf: Sharing PMU counters across compatible events
Date: Mon, 28 May 2018 13:15:49 +0200 [thread overview]
Message-ID: <20180528111549.GA3452@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <20180504231102.2850679-3-songliubraving@fb.com>
On Fri, May 04, 2018 at 04:11:02PM -0700, Song Liu wrote:
> Connection among perf_event and perf_event_dup are built with function
> rebuild_event_dup_list(cpuctx). This function is only called when events
> are added/removed or when a task is scheduled in/out. So it is not on
> critical path of perf_rotate_context().
Why is perf_rotate_context() the only critical path? I would say the
context switch path is rather critical too.
> @@ -2919,8 +3014,10 @@ static void ctx_sched_out(struct perf_event_context *ctx,
>
> if (ctx->task) {
> WARN_ON_ONCE(cpuctx->task_ctx != ctx);
> - if (!ctx->is_active)
> + if (!ctx->is_active) {
> cpuctx->task_ctx = NULL;
> + rebuild_event_dup_list(cpuctx);
> + }
> }
>
> /*
> +static void rebuild_event_dup_list(struct perf_cpu_context *cpuctx)
> +{
> + int dup_count = cpuctx->ctx.nr_events;
> + struct perf_event_context *ctx = cpuctx->task_ctx;
> + struct sched_in_data sid = {
> + .ctx = ctx,
> + .cpuctx = cpuctx,
> + .can_add_hw = 1,
> + };
> +
> + if (ctx)
> + dup_count += ctx->nr_events;
> +
> + kfree(cpuctx->dup_event_list);
> + cpuctx->dup_event_count = 0;
> +
> + cpuctx->dup_event_list =
> + kzalloc(sizeof(struct perf_event_dup) * dup_count, GFP_ATOMIC);
__schedule()
local_irq_disable()
raw_spin_lock(rq->lock)
context_switch()
prepare_task_switch()
perf_event_task_sched_out()
__perf_event_task_sched_out()
perf_event_context_sched_out()
task_ctx_sched_out()
ctx_sched_out()
rebuild_event_dup_list()
kzalloc()
...
spin_lock()
Also, as per the above, this nests a regular spin lock inside the
(raw) rq->lock, which is a no-no.
Not to mention that whole O(n) crud in the scheduling path...
next prev parent reply other threads:[~2018-05-28 12:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-04 23:11 [RFC 0/2] perf: Sharing PMU counters across compatible events Song Liu
2018-05-04 23:11 ` [RFC 1/2] perf: add move_dup() for PMU sharing Song Liu
2018-05-04 23:11 ` [RFC 2/2] perf: Sharing PMU counters across compatible events Song Liu
2018-05-28 11:15 ` Peter Zijlstra [this message]
2018-05-28 18:24 ` Song Liu
2018-05-28 11:24 ` Peter Zijlstra
2018-05-28 18:19 ` Song Liu
2018-05-28 11:26 ` Peter Zijlstra
2018-05-28 11:33 ` 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=20180528111549.GA3452@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=jolsa@kernel.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=songliubraving@fb.com \
--cc=tj@kernel.org \
/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.