mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.

  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