From: Peter Zijlstra <peterz@infradead.org>
To: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
linux-kernel@vger.kernel.org,
Kan Liang <kan.liang@linux.intel.com>,
Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH 3/7] perf: order iterators for visit_groups_merge into a min-heap
Date: Mon, 8 Jul 2019 18:30:21 +0200 [thread overview]
Message-ID: <20190708163021.GG3419@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20190702065955.165738-4-irogers@google.com>
On Mon, Jul 01, 2019 at 11:59:51PM -0700, Ian Rogers wrote:
> The groups rbtree holding perf events, either for a CPU or a task, needs
> to have multiple iterators that visit events in group_index (insertion)
> order. Rather than linearly searching the iterators, use a min-heap to go
> from a O(#iterators) search to a O(log2(#iterators)) insert cost per event
> visited.
Is this actually faster for the common (very small n) case?
ISTR 'stupid' sorting algorithms are actually faster when the data fits
into L1
> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
> kernel/events/core.c | 123 +++++++++++++++++++++++++++++++++----------
> 1 file changed, 95 insertions(+), 28 deletions(-)
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 9a2ad34184b8..396b5ac6dcd4 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -3318,6 +3318,77 @@ static void cpu_ctx_sched_out(struct perf_cpu_context *cpuctx,
> ctx_sched_out(&cpuctx->ctx, cpuctx, event_type);
> }
>
> +/* Data structure used to hold a min-heap, ordered by group_index, of a fixed
> + * maximum size.
> + */
Broken comment style.
> +struct perf_event_heap {
> + struct perf_event **storage;
> + int num_elements;
> + int max_elements;
> +};
> +
> +static void min_heap_swap(struct perf_event_heap *heap,
> + int pos1, int pos2)
> +{
> + struct perf_event *tmp = heap->storage[pos1];
> +
> + heap->storage[pos1] = heap->storage[pos2];
> + heap->storage[pos2] = tmp;
> +}
> +
> +/* Sift the perf_event at pos down the heap. */
> +static void min_heapify(struct perf_event_heap *heap, int pos)
> +{
> + int left_child, right_child;
> +
> + while (pos > heap->num_elements / 2) {
> + left_child = pos * 2;
> + right_child = pos * 2 + 1;
> + if (heap->storage[pos]->group_index >
> + heap->storage[left_child]->group_index) {
> + min_heap_swap(heap, pos, left_child);
> + pos = left_child;
> + } else if (heap->storage[pos]->group_index >
> + heap->storage[right_child]->group_index) {
> + min_heap_swap(heap, pos, right_child);
> + pos = right_child;
> + } else {
> + break;
> + }
> + }
> +}
> +
> +/* Floyd's approach to heapification that is O(n). */
> +static void min_heapify_all(struct perf_event_heap *heap)
> +{
> + int i;
> +
> + for (i = heap->num_elements / 2; i > 0; i--)
> + min_heapify(heap, i);
> +}
> +
> +/* Remove minimum element from the heap. */
> +static void min_heap_pop(struct perf_event_heap *heap)
> +{
> + WARN_ONCE(heap->num_elements <= 0, "Popping an empty heap");
> + heap->num_elements--;
> + heap->storage[0] = heap->storage[heap->num_elements];
> + min_heapify(heap, 0);
> +}
Is this really the first heap implementation in the kernel?
> @@ -3378,12 +3453,14 @@ static int visit_groups_merge(struct perf_event_context *ctx,
> struct cgroup_subsys_state *css;
>
> for (css = &cpuctx->cgrp->css; css; css = css->parent) {
> - itrs[num_itrs] = perf_event_groups_first(groups,
> + heap.storage[heap.num_elements] =
> + perf_event_groups_first(groups,
> cpu,
> css->cgroup);
> - if (itrs[num_itrs]) {
> - num_itrs++;
> - if (num_itrs == max_itrs) {
> + if (heap.storage[heap.num_elements]) {
> + heap.num_elements++;
> + if (heap.num_elements ==
> + heap.max_elements) {
> WARN_ONCE(
> max_cgroups_with_events_depth,
> "Insufficient iterators for cgroup depth");
That's turning into unreadable garbage due to indentation; surely
there's a solution for that.
next prev parent reply other threads:[~2019-07-08 16:30 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-02 6:59 [PATCH 0/7] Optimize cgroup context switch Ian Rogers
2019-07-02 6:59 ` [PATCH 1/7] perf: propagate perf_install_in_context errors up Ian Rogers
2019-07-05 14:13 ` Jiri Olsa
2019-07-02 6:59 ` [PATCH 2/7] perf/cgroup: order events in RB tree by cgroup id Ian Rogers
2019-07-08 15:38 ` Peter Zijlstra
2019-07-08 15:45 ` Peter Zijlstra
2019-07-08 16:16 ` Peter Zijlstra
2019-07-24 22:34 ` Ian Rogers
2019-07-08 16:21 ` Peter Zijlstra
2019-07-02 6:59 ` [PATCH 3/7] perf: order iterators for visit_groups_merge into a min-heap Ian Rogers
2019-07-08 16:30 ` Peter Zijlstra [this message]
2019-07-24 22:34 ` Ian Rogers
2019-07-08 16:36 ` Peter Zijlstra
2019-07-02 6:59 ` [PATCH 4/7] perf: avoid a bounded set of visit_groups_merge iterators Ian Rogers
2019-07-02 6:59 ` [PATCH 5/7] perf: cache perf_event_groups_first for cgroups Ian Rogers
2019-07-08 16:50 ` Peter Zijlstra
2019-07-08 16:51 ` Peter Zijlstra
2019-07-02 6:59 ` [PATCH 6/7] perf: avoid double checking CPU and cgroup Ian Rogers
2019-07-02 6:59 ` [PATCH 7/7] perf: rename visit_groups_merge to ctx_groups_sched_in Ian Rogers
2019-07-24 22:37 ` [PATCH v2 0/7] Optimize cgroup context switch Ian Rogers
2019-07-24 22:37 ` [PATCH v2 1/7] perf: propagate perf_install_in_context errors up Ian Rogers
2019-07-24 22:37 ` [PATCH v2 2/7] perf/cgroup: order events in RB tree by cgroup id Ian Rogers
2020-03-06 14:42 ` [tip: perf/core] perf/cgroup: Order " tip-bot2 for Ian Rogers
2019-07-24 22:37 ` [PATCH v2 3/7] perf: order iterators for visit_groups_merge into a min-heap Ian Rogers
2019-07-24 22:37 ` [PATCH v2 4/7] perf: avoid a bounded set of visit_groups_merge iterators Ian Rogers
2019-08-07 21:11 ` Peter Zijlstra
2019-07-24 22:37 ` [PATCH v2 5/7] perf: cache perf_event_groups_first for cgroups Ian Rogers
2019-07-24 22:37 ` [PATCH v2 6/7] perf: avoid double checking CPU and cgroup Ian Rogers
2019-07-24 22:37 ` [PATCH v2 7/7] perf: rename visit_groups_merge to ctx_groups_sched_in Ian Rogers
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=20190708163021.GG3419@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=eranian@google.com \
--cc=irogers@google.com \
--cc=jolsa@redhat.com \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--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
Powered by JetHome