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: 10+ 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox