[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201109095235.GC2594@hirez.programming.kicks-ass.net>
Date: Mon, 9 Nov 2020 10:52:35 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: kan.liang@...ux.intel.com
Cc: mingo@...nel.org, linux-kernel@...r.kernel.org,
namhyung@...nel.org, eranian@...gle.com, irogers@...gle.com,
gmx@...gle.com, acme@...nel.org, jolsa@...hat.com,
ak@...ux.intel.com
Subject: Re: [PATCH 1/3] perf/core: Flush PMU internal buffers for per-CPU
events
On Fri, Nov 06, 2020 at 01:29:33PM -0800, kan.liang@...ux.intel.com wrote:
> From: Kan Liang <kan.liang@...ux.intel.com>
>
> Sometimes the PMU internal buffers have to be flushed for per-CPU events
> during a context switch, e.g., large PEBS. Otherwise, the perf tool may
> report samples in locations that do not belong to the process where the
> samples are processed in, because PEBS does not tag samples with PID/TID.
>
> The current code only flush the buffers for a per-task event. It doesn't
> check a per-CPU event.
>
> Add a new event state flag, PERF_ATTACH_SCHED_CB, to indicate that the
> PMU internal buffers have to be flushed for this event during a context
> switch.
>
> Add sched_cb_entry and perf_sched_cb_usages back to track the PMU/cpuctx
> which is required to be flushed.
>
> Only need to invoke the sched_task() for per-CPU events in this patch.
> The per-task events have been handled in perf_event_context_sched_in/out
> already.
>
> Fixes: 9c964efa4330 ("perf/x86/intel: Drain the PEBS buffer during context switches")
Are you sure? In part this patch looks like a revert of:
44fae179ce73a26733d9e2d346da4e1a1cb94647
556cccad389717d6eb4f5a24b45ff41cad3aaabf
> +static void perf_pmu_sched_task(struct task_struct *prev,
> + struct task_struct *next,
> + bool sched_in)
> +{
> + struct perf_cpu_context *cpuctx;
> +
> + if (prev == next)
> + return;
> +
> + list_for_each_entry(cpuctx, this_cpu_ptr(&sched_cb_list), sched_cb_entry) {
> + /* will be handled in perf_event_context_sched_in/out */
> + if (cpuctx->task_ctx)
> + continue;
This seems wrong; cpuctx->task_ctx merely indicates that there is a
task-ctx for this CPU. Not that the event you're interested in is in
fact there.
So consider the case where the event is on the CPU context, but we also
have a task context. Then we'll not issue this call.
> +
> + __perf_pmu_sched_task(cpuctx, sched_in);
> + }
> +}
Powered by blists - more mailing lists