From: Peter Zijlstra <peterz@infradead.org>
To: "Liang, Kan" <kan.liang@linux.intel.com>
Cc: mingo@redhat.com, linux-kernel@vger.kernel.org, acme@kernel.org,
mark.rutland@arm.com, ak@linux.intel.com,
alexander.shishkin@linux.intel.com, namhyung@kernel.org,
jolsa@redhat.com
Subject: Re: [PATCH 0/4] perf: Fix the ctx->pmu for a hybrid system
Date: Thu, 17 Jun 2021 21:32:55 +0200 [thread overview]
Message-ID: <YMujZ7a/8ToWXzo+@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <3d4b9377-30b0-a945-7b11-b412dcc4c51a@linux.intel.com>
On Thu, Jun 17, 2021 at 10:10:37AM -0400, Liang, Kan wrote:
> I think all the perf_sw_context PMUs share the same pmu_cpu_context. so the
> cpuctx->ctx.pmu should be always the first registered perf_sw_context PMU
> which is perf_swevent. The ctx->pmu could be another software PMU.
Is there actually anything that relies on that? IIRC the sw pmus only
use event->pmu->foo() methods (exactly because the ctx->pmu is
unreliable for them).
> In theory, the perf_sw_context PMUs should have a similar issue. If the
> events are from different perf_sw_context PMUs, we should perf_pmu_disable()
> all of the PMUs before schedule them, but the ctx->pmu only tracks the first
> one.
>
> I don't have a good way to fix the perf_sw_context PMUs. I think we have to
> go through the event list and find all PMUs. But I don't think it's worth
> doing.
Yeah, the software PMUs are misserable, they're one of the things I wish
I'd done differently. Cleaning that up is *somewhere* on the TODO list.
So I *think* it should work as is and we can avoid the extra check, but
let me know what actual testing does.
next prev parent reply other threads:[~2021-06-17 19:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-16 18:55 [PATCH 0/4] perf: Fix the ctx->pmu for a hybrid system kan.liang
2021-06-16 18:55 ` [PATCH 1/4] perf: Update " kan.liang
2021-06-16 18:55 ` [PATCH 2/4] perf/x86: Fix the x86_pmu_start WARNING on " kan.liang
2021-06-16 18:55 ` [PATCH 3/4] perf: Check the supported CPU of an event kan.liang
2021-06-16 18:55 ` [PATCH 4/4] perf/x86: Remove filter_match callback kan.liang
2021-06-17 10:23 ` [PATCH 0/4] perf: Fix the ctx->pmu for a hybrid system Peter Zijlstra
2021-06-17 11:33 ` Peter Zijlstra
2021-06-17 14:10 ` Liang, Kan
2021-06-17 19:32 ` Peter Zijlstra [this message]
2021-06-18 13:54 ` Liang, Kan
2021-06-24 7:09 ` [tip: perf/core] perf: Fix task context PMU for Hetero tip-bot2 for Peter Zijlstra
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=YMujZ7a/8ToWXzo+@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=jolsa@redhat.com \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--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 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.