All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: kan.liang@linux.intel.com
Cc: mingo@redhat.com, linux-kernel@vger.kernel.org, robh@kernel.org,
	ak@linux.intel.com, acme@kernel.org, mark.rutland@arm.com,
	luto@amacapital.net, eranian@google.com, namhyung@kernel.org
Subject: Re: [PATCH V7 1/2] perf: Track per-PMU sched_task() callback users
Date: Thu, 13 May 2021 16:42:57 +0200	[thread overview]
Message-ID: <YJ068cA0bGJA0C0T@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <1620915782-50154-1-git-send-email-kan.liang@linux.intel.com>

On Thu, May 13, 2021 at 07:23:01AM -0700, kan.liang@linux.intel.com wrote:
> From: Kan Liang <kan.liang@linux.intel.com>
> 
> Current perf only tracks the per-CPU sched_task() callback users, which
> doesn't work if a callback user is a task. For example, the dirty
> counters have to be cleared to prevent data leakage when a new RDPMC
> task is scheduled in. The task may be created on one CPU but running on
> another CPU. It cannot be tracked by the per-CPU variable. A global
> variable is not going to work either because of the hybrid PMUs.
> Add a per-PMU variable to track the callback users.
> 
> In theory, the per-PMU variable should be checked everywhere the
> sched_task() can be called. But the X86 RDPMC is the only user for the
> per-PMU sched_cb_usage. A callback for the X86 RDPMC is required only
> when a different context is scheduled in. To avoid unnecessary
> sched_task() invoke, the per-PMU sched_cb_usage is only checked there.
> Should there be any other ARCHs which require it in the other places,
> it can be added later separately.
> 
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
> ---
> 
> - New patch. Split the V6 to core and x86 parts.
> 
>  include/linux/perf_event.h | 3 +++
>  kernel/events/core.c       | 9 ++++++++-
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index c8a3388..c6ee202 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -301,6 +301,9 @@ struct pmu {
>  	/* number of address filters this PMU can do */
>  	unsigned int			nr_addr_filters;
>  
> +	/* Track the per PMU sched_task() callback users */
> +	atomic_t			sched_cb_usage;
> +
>  	/*
>  	 * Fully disable/enable this PMU, can be used to protect from the PMI
>  	 * as well as for lazy/batch writing of the MSRs.
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 1574b70..286b718 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -3851,7 +3851,14 @@ static void perf_event_context_sched_in(struct perf_event_context *ctx,
>  		cpu_ctx_sched_out(cpuctx, EVENT_FLEXIBLE);
>  	perf_event_sched_in(cpuctx, ctx, task);
>  
> -	if (cpuctx->sched_cb_usage && pmu->sched_task)
> +	/*
> +	 * X86 RDPMC is the only user for the per-PMU sched_cb_usage.

I think we can do without this line; since we know ARM64 also
potentially wants this.

> +	 * A callback for the X86 RDPMC is required only when a

Also, I think we spell it: x86.

> +	 * different context is scheduled in.
> +	 * To avoid unnecessary sched_task() invoke, the per-PMU
> +	 * sched_cb_usage is only checked here.
> +	 */
> +	if (pmu->sched_task && (cpuctx->sched_cb_usage || atomic_read(&pmu->sched_cb_usage)))
>  		pmu->sched_task(cpuctx->task_ctx, true);
>  
>  	perf_pmu_enable(pmu);

I'll sit on these patches a wee bit until Rob has provided feedback, but
I'm thinking this should do.

      parent reply	other threads:[~2021-05-13 14:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-13 14:23 [PATCH V7 1/2] perf: Track per-PMU sched_task() callback users kan.liang
2021-05-13 14:23 ` [PATCH V7 2/2] perf/x86: Reset the dirty counter to prevent the leak for an RDPMC task kan.liang
2021-05-13 15:02   ` Peter Zijlstra
2021-05-13 22:14     ` Liang, Kan
2021-05-14  3:50       ` Rob Herring
2021-05-14 13:48         ` Liang, Kan
2021-05-14 14:44       ` Peter Zijlstra
2021-05-14 15:30         ` Liang, Kan
2021-05-13 14:42 ` Peter Zijlstra [this message]

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=YJ068cA0bGJA0C0T@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=eranian@google.com \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=robh@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 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.