Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1306473 > unrolled thread

[RFC][PATCH 02/12] perf: Fix cgroup event scheduling

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [RFC][PATCH 02/12] perf: Fix cgroup event scheduling Peter Zijlstra <peterz@infradead.org> - 2016-01-11 17:40 +0100
    Re: [RFC][PATCH 02/12] perf: Fix cgroup event scheduling Stephane Eranian <eranian@google.com> - 2016-01-11 20:50 +0100
      Re: [RFC][PATCH 02/12] perf: Fix cgroup event scheduling Peter Zijlstra <peterz@infradead.org> - 2016-01-11 23:10 +0100

#1306473 — [RFC][PATCH 02/12] perf: Fix cgroup event scheduling

There appears to be a problemin __perf_event_task_sched_in() wrt
cgroup event scheduling.

The normal event scheduling order is:

	CPU pinned
	Task pinned
	CPU flexible
	Task flexible

And since perf_cgroup_sched*() only schedules the cpu context, we must
call this _before_ adding the task events.

Note: double check what happens on the ctx switch optimization where
the task ctx isn't scheduled.

Cc: Stephane Eranian <eranian@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 kernel/events/core.c |   17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2804,6 +2804,16 @@ void __perf_event_task_sched_in(struct t
 	struct perf_event_context *ctx;
 	int ctxn;
 
+	/*
+	 * If cgroup events exist on this CPU, then we need to check if we have
+	 * to switch in PMU state; cgroup event are system-wide mode only.
+	 *
+	 * Since cgroup events are CPU events, we must schedule these in before
+	 * we schedule in the task events.
+	 */
+	if (atomic_read(this_cpu_ptr(&perf_cgroup_events)))
+		perf_cgroup_sched_in(prev, task);
+
 	for_each_task_context_nr(ctxn) {
 		ctx = task->perf_event_ctxp[ctxn];
 		if (likely(!ctx))
@@ -2811,13 +2821,6 @@ void __perf_event_task_sched_in(struct t
 
 		perf_event_context_sched_in(ctx, task);
 	}
-	/*
-	 * if cgroup events exist on this CPU, then we need
-	 * to check if we have to switch in PMU state.
-	 * cgroup event are system-wide mode only
-	 */
-	if (atomic_read(this_cpu_ptr(&perf_cgroup_events)))
-		perf_cgroup_sched_in(prev, task);
 
 	if (atomic_read(&nr_switch_events))
 		perf_event_switch(task, prev, true);

[toc] | [next] | [standalone]

#1306633

Peter,

On Mon, Jan 11, 2016 at 8:25 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> There appears to be a problemin __perf_event_task_sched_in() wrt
> cgroup event scheduling.
>
> The normal event scheduling order is:
>
>         CPU pinned
>         Task pinned
>         CPU flexible
>         Task flexible
>
> And since perf_cgroup_sched*() only schedules the cpu context, we must
> call this _before_ adding the task events.
>
I understand this but I am trying to understand why cgroup system-wide event
would be treated differently from regular system-wide events w.r.t. task events
here. If I do a cgroup flexible and a task pinned, what happens?

> Note: double check what happens on the ctx switch optimization where
> the task ctx isn't scheduled.
>
> Cc: Stephane Eranian <eranian@google.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
>  kernel/events/core.c |   17 ++++++++++-------
>  1 file changed, 10 insertions(+), 7 deletions(-)
>
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -2804,6 +2804,16 @@ void __perf_event_task_sched_in(struct t
>         struct perf_event_context *ctx;
>         int ctxn;
>
> +       /*
> +        * If cgroup events exist on this CPU, then we need to check if we have
> +        * to switch in PMU state; cgroup event are system-wide mode only.
> +        *
> +        * Since cgroup events are CPU events, we must schedule these in before
> +        * we schedule in the task events.
> +        */
> +       if (atomic_read(this_cpu_ptr(&perf_cgroup_events)))
> +               perf_cgroup_sched_in(prev, task);
> +
>         for_each_task_context_nr(ctxn) {
>                 ctx = task->perf_event_ctxp[ctxn];
>                 if (likely(!ctx))
> @@ -2811,13 +2821,6 @@ void __perf_event_task_sched_in(struct t
>
>                 perf_event_context_sched_in(ctx, task);
>         }
> -       /*
> -        * if cgroup events exist on this CPU, then we need
> -        * to check if we have to switch in PMU state.
> -        * cgroup event are system-wide mode only
> -        */
> -       if (atomic_read(this_cpu_ptr(&perf_cgroup_events)))
> -               perf_cgroup_sched_in(prev, task);
>
>         if (atomic_read(&nr_switch_events))
>                 perf_event_switch(task, prev, true);
>
>

[toc] | [prev] | [next] | [standalone]

#1306743

On Mon, Jan 11, 2016 at 11:43:40AM -0800, Stephane Eranian wrote:
> Peter,
> 
> On Mon, Jan 11, 2016 at 8:25 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > There appears to be a problemin __perf_event_task_sched_in() wrt
> > cgroup event scheduling.
> >
> > The normal event scheduling order is:
> >
> >         CPU pinned
> >         Task pinned
> >         CPU flexible
> >         Task flexible
> >
> > And since perf_cgroup_sched*() only schedules the cpu context, we must
> > call this _before_ adding the task events.
> >
> I understand this but I am trying to understand why cgroup system-wide event
> would be treated differently from regular system-wide events w.r.t. task events
> here. 

This patch is about making cgroup events behave similarly to regular
system-wide events.

> If I do a cgroup flexible and a task pinned, what happens?

Look at perf_event_context_sched_in(), it will first remove the
cpu-flexible and then install everything:

  cpu-pinned (skipped, because that would still be present)
  task-pinned (new)
  cpu-flexible (re-issue, possibly truncated due to the new pinned events)
  task-flexible (new)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web