From: Peter Zijlstra <peterz@infradead.org>
To: mingo@kernel.org, linux-kernel@vger.kernel.org
Cc: acme@kernel.org, mark.rutland@arm.com,
alexander.shishkin@linux.intel.com, jolsa@redhat.com,
namhyung@kernel.org, andi@firstfloor.org,
kan.liang@linux.intel.com
Subject: Re: [PATCH 1/3] perf: Optimize perf_install_in_event()
Date: Tue, 22 Oct 2019 12:03:55 +0200 [thread overview]
Message-ID: <20191022100355.GM1817@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20191022092307.368892814@infradead.org>
On Tue, Oct 22, 2019 at 11:20:18AM +0200, Peter Zijlstra wrote:
> Andi reported that when creating a lot of events, a lot of time is
> spend in IPIs and asked if it would be possible to elide some of that.
>
> Now when, as for example the perf-tool always does, events are created
> disabled, then these events will not need to be scheduled when added
> to the context (they're still disable) and therefore the IPI is not
> required -- except for the very first event, that will need to set
> ctx->is_active.
>
> ( it might be possible to set ctx->is_active remotely for cpu_ctx, but
> we really need the IPI for task_ctx, so lets not make that
> distinction )
>
> Also use __perf_effective_state() since group events depend on the
> state of the leader, if the leader is OFF, the whole group is OFF.
>
> So when sibling events are created enabled (XXX check tool) then we
> only need a single IPI to create and enable the whole group (+ that
> initial IPI to initialize the context).
Arguably, we could possible do something like so as well, but I'm not
sure it makes sense as it will not help if IOC_ENABLE is called in
creation order. Because in that case we'll enable the group leader
before the siblings and we'll schedule them one at a time, instead of
the whole group at once.
---
diff --git a/kernel/events/core.c b/kernel/events/core.c
index f9a5d4356562..2a5e6d9654e1 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2791,6 +2791,7 @@ static void __perf_event_enable(struct perf_event *event,
static void _perf_event_enable(struct perf_event *event)
{
struct perf_event_context *ctx = event->ctx;
+ struct perf_event *leader;
raw_spin_lock_irq(&ctx->lock);
if (event->state >= PERF_EVENT_STATE_INACTIVE ||
@@ -2808,6 +2809,17 @@ static void _perf_event_enable(struct perf_event *event)
*/
if (event->state == PERF_EVENT_STATE_ERROR)
event->state = PERF_EVENT_STATE_OFF;
+
+ /*
+ * If this is a sibling event and the group leader is still OFF
+ * then there is no point in trying to schedule this event.
+ */
+ leader = event->group_leader;
+ if (leader != event && leader->state == PERF_EVENT_STATE_OFF) {
+ event->state = PERF_EVENT_STATE_INACTIVE;
+ raw_spin_unlock_irq(&ctx->lock);
+ return;
+ }
raw_spin_unlock_irq(&ctx->lock);
event_function_call(event, __perf_event_enable, NULL);
next prev parent reply other threads:[~2019-10-22 10:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-22 9:20 [PATCH 0/3] Various optimizations for event creation Peter Zijlstra
2019-10-22 9:20 ` [PATCH 1/3] perf: Optimize perf_install_in_event() Peter Zijlstra
2019-10-22 10:03 ` Peter Zijlstra [this message]
2019-10-23 12:30 ` Alexander Shishkin
2019-10-23 13:44 ` Peter Zijlstra
2019-10-23 14:08 ` Peter Zijlstra
2019-10-22 9:20 ` [PATCH 2/3] perf: Optimize perf_init_event() Peter Zijlstra
2019-10-27 5:18 ` [perf] 06e0dbcfd3: phoronix-test-suite.mbw.0.mib_s 12.6% improvement kernel test robot
2019-10-27 5:18 ` kernel test robot
2019-10-27 16:32 ` Andi Kleen
2019-10-22 9:20 ` [PATCH 3/3] perf: Optimize perf_init_event() for TYPE_SOFTWARE 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=20191022100355.GM1817@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=jolsa@redhat.com \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=namhyung@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.