All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Alexey Budankov <alexey.budankov@linux.intel.com>
Cc: Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Andi Kleen <ak@linux.intel.com>, Kan Liang <kan.liang@intel.com>,
	Dmitri Prokhorov <Dmitry.Prohorov@intel.com>,
	Valery Cherepennikov <valery.cherepennikov@intel.com>,
	David Carrillo-Cisneros <davidcc@google.com>,
	Stephane Eranian <eranian@google.com>,
	Mark Rutland <mark.rutland@arm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2]: perf/core: addressing 4x slowdown during per-process, profiling of STREAM benchmark on Intel Xeon Phi
Date: Mon, 29 May 2017 09:45:06 +0200	[thread overview]
Message-ID: <20170529074506.brvayqdp6xcxbhs7@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <b410f376-69ed-c681-8413-c4186bc74aed@linux.intel.com>

On Sat, May 27, 2017 at 02:19:51PM +0300, Alexey Budankov wrote:
> Solution:
> 
> cpu indexed trees for perf_event_context::pinned_groups and
> perf_event_context::flexible_groups lists are introduced. Every tree node
> keeps a list of groups allocated for the same cpu. A tree references only
> groups located at the appropriate group list. The tree provides capability
> to iterate over groups allocated for a specific cpu only, what is exactly
> required by multiplexing timer interrupt handler. The handler runs per-cpu
> and enables/disables groups using group_sched_in()/group_sched_out() that
> call event_filter_match() function filtering out groups allocated for cpus
> different from the one executing the handler. Additionally for every
> filtered out group group_sched_out() updates tstamps values to the current
> interrupt time. This updating work is now done only once by
> update_context_time() called by ctx_sched_out() before cpu groups
> iteration. For this trick to work it is required that tstamps of filtered
> out events would point to perf_event_context::tstamp_data object instead
> of perf_event::tstamp_data ones, as it is initialized from an event
> allocation. tstamps references are switched by
> group_sched_in()/group_sched_out() every time a group is checked for its
> suitability for currently running cpu. When a thread enters some cpu on
> a context switch a long run through pinned and flexible groups is
> performed by perf_event_sched_in(, mux=0) with new parameter mux set to 0
> and filtered out groups tstamps are switched to
> perf_event_context::tstamp_data object. Then a series of multiplexing
> interrupts happens and the handler rotates the flexible groups calling
> ctx_sched_out(,mux=1)/perf_event_sched_in(,mux=1) iterating over the cpu
> tree lists only and avoiding long runs through the complete group lists.
> This is where speedup comes from. Eventually when the thread leaves the cpu
> ctx_sched_out(,mux=0) is called restoring tstamps pointers to the events'
> perf_event::tstamp_data objects.

This is unreadable.. Please use whitespace.


> Added API:
> 
> Objects:
> 1. struct perf_event_tstamp:
>    - enabled
>    - running
>    - stopped
> 2. struct perf_event:
>    - group_node
>    - group_list
>    - group_list_entry
>    - tstamp
>    - tstamp_data
> 3. struct perf_event_context:
>    - pinned_tree
>    - flexible_tree
>    - tstamp_data
> 
> Functions:
> 1. insert a group into a tree using event->cpu as a key:
> 	int perf_cpu_tree_insert(struct rb_root *tree,
> 		struct perf_event *event);
> 2. delete a group from a tree, if the group is directly attached
>    to a tree it also detaches all groups on the groups
>    group_list list:
> 	int perf_cpu_tree_delete(struct rb_root *tree,
> 		struct perf_event *event);
> 3. find group_list list by a cpu key:
>         struct list_head * perf_cpu_tree_find(struct rb_root *tree,
> 		int cpu);
> 4. enable a pinned group on a cpu:
>         void ctx_sched_in_flexible_group(struct perf_event_context *ctx,
> 		struct perf_cpu_context *cpuctx,
> 		struct perf_event *group, int *can_add_hw);
> 5. enable a flexible group on a cpu; calls ctx_sched_in_flexible_group
>    and updates group->state to ERROR in case of failure:
> 	void ctx_sched_in_pinned_group(struct perf_event_context *ctx,
> 		struct perf_cpu_context *cpuctx,
> 		struct perf_event *group);
> 6. enable per-cpu pinned tree's groups on a cpu:
> 	void ctx_pinned_sched_in_groups(struct perf_event_context *ctx,
> 		struct perf_cpu_context *cpuctx,
> 		struct list_head *groups);
> 7. enable per-cpu flexible tree's groups on a cpu:
> 	void ctx_flexible_sched_in_groups(
> 		struct perf_event_context *ctx,
> 		struct perf_cpu_context *cpuctx,
> 		struct list_head *groups);
> 8. disable per-cpu tree's groups on a cpu:
> 	void ctx_sched_out_groups(struct perf_event_context *ctx,
> 		struct perf_cpu_context *cpuctx,
> 		struct list_head *groups);
> 9. get a group tree based on event->attr.pinned attribute value:
> 	struct rb_root * ctx_cpu_tree(struct perf_event *event,
> 		struct perf_event_context *ctx);
> 
> Modified API:
> 
> Objects:
> 1. struct perf_event
> 2. struct perf_event_context
> 
> Functions:
> 1. perf_event_alloc()
> 2. add_event_to_ctx()
> 3. perf_event_enable_on_exec()
> 4. __perf_install_in_context()
> 5. __perf_event_init_context()
> 6. __perf_event_mark_enabled()
> 7. __perf_event_enable()
> 8. __perf_event_task_sched_out()
> 9. ctx_group_list()
> 10. list_add_event()
> 11. list_del_event()
> 12. perf_event_context_sched_in()
> 13. cpu_ctx_sched_in()
> 14. cpu_ctx_sched_out()
> 15. ctx_sched_in()
> 16. ctx_sched_out()
> 17. ctx_resched()
> 18. ctx_pinned_sched_in()
> 19. ctx_flexible_sched_in()
> 20. group_sched_in()
> 21. event_sched_in()
> 22. event_sched_out()
> 23. rotate_ctx()
> 24. perf_rotate_context()
> 25. update_context_time()
> 26. update_event_times()
> 27. calc_timer_values()
> 28. perf_cgroup_switch()
> 29. perf_cgroup_mark_enabled()

Yeah, this doesn't go into a changelog. Have you _ever_ seen a changelog
with such crud in?

  reply	other threads:[~2017-05-29  7:45 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-26 22:13 [PATCH]: perf/core: addressing 4x slowdown during per-process profiling of STREAM benchmark on Intel Xeon Phi Alexey Budankov
2017-05-27 11:19 ` [PATCH v2]: perf/core: addressing 4x slowdown during per-process, " Alexey Budankov
2017-05-29  7:45   ` Peter Zijlstra [this message]
2017-05-29  9:24     ` Alexey Budankov
2017-05-29 10:33       ` Peter Zijlstra
2017-05-29 10:46         ` Alexey Budankov
2017-05-29  7:46   ` Peter Zijlstra
2017-05-29  9:15     ` Alexey Budankov
2017-05-29 10:43       ` Peter Zijlstra
2017-05-29 10:56         ` Alexey Budankov
2017-05-29 11:23           ` Peter Zijlstra
2017-05-29 11:45             ` Alexey Budankov
2017-06-15 17:42               ` Alexey Budankov
2017-06-21 15:39                 ` Alexey Budankov
2017-06-30 10:22                   ` Alexey Budankov
2017-05-31 21:33   ` David Carrillo-Cisneros
2017-06-14 11:27     ` Alexey Budankov
2017-05-29 12:03 ` [PATCH]: perf/core: addressing 4x slowdown during per-process " Alexander Shishkin
2017-05-29 13:43   ` Alexey Budankov
2017-05-29 15:22     ` Peter Zijlstra
2017-05-29 15:29       ` Peter Zijlstra
2017-05-29 16:41         ` Alexey Budankov
2017-05-30  8:29     ` Alexander Shishkin
2017-06-14 10:07       ` Alexey Budankov
2017-06-15 17:44         ` Alexey Budankov
2017-05-31  0:04 [PATCH v2]: perf/core: addressing 4x slowdown during per-process, " Arun Kalyanasundaram
2017-06-14 12:26 ` Alexey Budankov

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=20170529074506.brvayqdp6xcxbhs7@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=Dmitry.Prohorov@intel.com \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=alexey.budankov@linux.intel.com \
    --cc=davidcc@google.com \
    --cc=eranian@google.com \
    --cc=kan.liang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=valery.cherepennikov@intel.com \
    /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.